Active Directory

Active Directory® is a directory service that stores information about objects on a network and makes this information available to users and network administrators.

  • Before deploying Active Directory, see Checklists.
  • To find administrative tool equivalents that have changed from Windows NT® 4.0 Server, see New ways to do familiar tasks.
  • For tips about using Active Directory, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.


Checklists

  • Checklist: Creating a new forest
  • Checklist: Creating a new child domain
  • Checklist: Creating a new domain tree
  • Checklist: Creating an additional domain controller in an existing domain
  • Checklist: Creating a group
  • Checklist: Configuring a site
  • Checklist: Optimizing intersite replication
  • Checklist: Creating a forest trust


Checklist: Creating a new forest

Step | Reference
(Optional) Review concepts and key DNS implications to consider before setting up a new forest. | Creating a new forest
(Optional) Review concepts about security and other options available when using the Active Directory Installation Wizard. | Using the Active Directory Installation Wizard
Verify that the server on which you will be installing Active Directory has an NTFS partition. | Reformatting or converting a partition to use NTFS
(Optional) Review the role of a domain controller. | Domain controllers
(Optional) Review concepts on Domain Name System (DNS) namespace planning and how Active Directory is integrated with DNS. | Namespace planning for DNS; To configure a DNS server for use with Active Directory; DNS integration
Verify that you are a member of the Administrators group on the server on which you will be installing Active Directory. | Default groups
Verify that DNS is properly configured before installing Active Directory. | Checklist: Verifying DNS before installing Active Directory
Create the domain controller. | To create a new forest


Checklist: Creating a new child domain

Step | Reference
(Optional) Review concepts about adding new child domains. | Creating a new child domain
(Optional) Review concepts about security and other options available when using the Active Directory Installation Wizard. | Using the Active Directory Installation Wizard
Verify that the server on which you will be installing Active Directory has an NTFS partition. | Reformatting or converting a partition to use NTFS
Verify that you are a member of the Enterprise Admins group or the Domain Admins group of the parent domain. | Default groups
Verify that DNS is properly configured before installing Active Directory. | Checklist: Verifying DNS before installing Active Directory
Create the domain controller. | To create a new child domain


Checklist: Creating a new domain tree

Step | Reference
(Optional) Review concepts about adding new domain trees. | Creating a new domain tree
(Optional) Review concepts about security and other options available when using the Active Directory Installation Wizard. | Using the Active Directory Installation Wizard
Verify that the server on which you will be installing Active Directory has an NTFS partition. | Reformatting or converting a partition to use NTFS
Verify that you are a member of the Enterprise Admins group or the Domain Admins group in the forest root domain. | Default groups
Verify that DNS is properly configured before installing Active Directory. | Checklist: Verifying DNS before installing Active Directory
Create the domain controller. | To create a new domain tree


Checklist: Creating an additional domain controller in an existing domain

Step | Reference
(Optional) Review concepts about creating additional domain controllers over the network or by using backup media. | Creating additional domain controllers
(Optional) Review concepts about security and other options available when using the Active Directory Installation Wizard. | Using the Active Directory Installation Wizard
Verify that the server on which you will be installing Active Directory has an NTFS partition. | Reformatting or converting a partition to use NTFS
(Optional) Review the role of a domain controller. | Domain controllers
Verify that you are a member of the Domain Admins group in the domain where you will be adding the domain controller. | Default groups
Verify that DNS is properly configured before installing Active Directory. | Checklist: Verifying DNS before installing
Create the domain controller. | To create an additional domain controller


Checklist: Creating a group

Step | Reference
(Optional) Review concepts about groups. | Groups; Understanding groups
Identify which type of group (security or distribution) you want to create. | Group types
Identify which scope (universal, global, or domain local) you want to create for the group. | Group scope
Use the appropriate administrative tool to create the group:
  • To create a local group on a workstation or member server, use Local Users and Groups in Computer Management.
  • To create a group in a Windows Server 2003 domain, use Active Directory Users and Computers.
 To create a local group; To create a new group


Checklist: Configuring a site

Step | Reference
(Optional) Review sites and replication concepts. | Sites overview; Replication overview; Managing replication
Create a new site. | To create a site
Associate a subnet with a site. | To associate a subnet with a site
Connect the site. | To create a site link; To add a site to a site link
Customize replication. | Checklist: Optimizing intersite replication


Checklist: Optimizing intersite replication

Step | Reference
(Optional) Review sites and replication concepts. | Sites overview; Replication overview; Managing replication
Create site links. | To create a site link
Configure site link cost. | To configure site link cost; To configure site link replication availability


Checklist: Creating a forest trust

Step | Reference
(Optional) Review the various trust types and understand forest trust concepts. | Trust types; Forest trusts; When to create a forest trust; Accessing resources across forests; Routing name suffixes across forests
Ensure that Domain Name System (DNS) is properly set up.

If there is a root DNS server that can be made the root DNS server for both of the forest DNS namespaces, then make it the root server by ensuring that the root zone contains delegations for each of the DNS namespaces. Also, update the root hints of all DNS servers with the new root DNS server.

If there is no shared root DNS server, and the root DNS servers for each forest DNS namespace are running a member of the Windows Server 2003 family, then configure DNS conditional forwarders in each DNS namespace to route queries for names in the other namespace.

If there is no shared root DNS server, and the root DNS servers for each forest DNS namespace are not running a member of the Windows Server 2003 family, then configure DNS secondary zones in each DNS namespace to route queries for names in the other namespace.

 To verify a zone delegation using the nslookup command; To update root hints on the DNS server; To configure a DNS server to use forwarders; To add a secondary server for an existing zone; Namespace planning for DNS
Set the forest functional level in both forests to Windows Server 2003. | To raise the forest functional level
Create a forest trust. | To create a forest trust


New ways to do familiar tasks

The following table lists common tasks for configuring Active Directory. The user interface for performing these tasks is different in this version of Windows from the way it was in Windows NT version 4.0.

Note

  • There are no significant user interface differences between Windows 2000 and the Windows Server 2003 family of products for this component.
If you want to | In Windows NT 4.0 use | In this version of Windows use
Install a domain controller | Windows Setup | The Active Directory Installation Wizard. For more information, see Using the Active Directory Installation Wizard;To create a new forest ;To create a new domain tree;To create a new child domain;To create an additional domain controller.
Manage users | User Manager | Active Directory Users and Computers. For more information, see Manage users.
Manage groups | User Manager | Active Directory Users and Computers. For more information, see Manage groups.
Manage computer accounts | Server Manager | Active Directory Users and Computers. For more information, see Manage computers.
Add a computer to a domain | Server Manager | Active Directory Users and Computers. For more information, see Manage computers.
Create or manage trust relationships | User Manager | Active Directory Domains and Trusts. For more information, see Manage trusts.
Manage account policy | User Manager | Active Directory Users and Computers. For more information, see Account and local policies.
Manage user rights | User Manager | Active Directory Users and Computers. Edit the Group Policy object for the domain or organizational unit containing the computers to which the user rights apply. For more information, see To edit a security setting on a Group Policy object.
Manage audit policy | User Manager | Active Directory Users and Computers. Edit the Group Policy object assigned to the Domain Controllers organizational unit. For more information, see To edit a security setting on a Group Policy object.


Best practices

  • As a security best practice, it is recommended that you do not log on to your computer with administrative credentials.

    • When you are logged on to your computer without administrative credentials, you can use Run as to accomplish administrative tasks.

    For more information, see Why you should not run your computer as an administrator and Using Run as.

  • To further secure Active Directory, it is recommended that you implement the following security guidelines:
    • Rename or disable the Administrator account (and guest account) in each domain to prevent attacks on your domains. For more information, see User and computer accounts.
    • Physically secure all domain controllers in a locked room. For more information, see Domain controllers and Securing Active Directory.
    • Manage the security relationship between two forests and simplify security administration and authentication across forests. For more information, see Forest trusts.
    • To provide additional protection for the Active Directory schema, remove all users from the Schema Admins group, and add a user to the group only when schema changes need to be made. Once the change has been made remove the user from the group.
    • Restrict user, group, and computer access to shared resources and to filter Group Policy settings. For more information, see Security groups.
    • Avoid disabling the use of signed or encrypted LDAP traffic for Active Directory administrative tools. For more information, see Connecting to domain controllers running Windows 2000.
    • Some default user rights assigned to specific default groups may allow members of those groups to gain additional rights in the domain, including administrative rights. Therefore, your organization must equally trust all personnel that are members of the Enterprise Admins, Domain Admins, Account Operators, Server Operators, Print Operators and Backup Operators groups. For more information about these groups, see Default Groups.
    • Use global groups or universal groups instead of domain local groups when specifying permissions on domain directory objects replicated to the global catalog. For more information, see Global catalog replication.

      For general security information about Active Directory, see Security information for Active Directory and Securing Active Directory.

  • Establish as a site every geographic area that requires fast access to the latest directory information.

    Establishing areas that require immediate access to up-to-date Active Directory information as separate sites will provide the resources required to meet your needs.

    For more information, see To create a site.

  • Place at least one domain controller in every site, and make at least one domain controller in each site a global catalog.

    Sites that do not have their own domain controllers and at least one global catalog are dependent on other sites for directory information and are less efficient.

    For more information, see To enable or disable a global catalog.

  • Perform regular backups of domain controllers in order to preserve all trust relationships within that domain.

    For more information, see Domain controllers.


How to...

  • Manage users, groups, and computers
  • Publish resources
  • Manage domains
  • Manage operations master roles
  • Manage trusts
  • Manage forests
  • Manage sites
  • Manage COM+ partitions and partition sets
  • Search Active Directory


Manage users, groups, and computers

  • Manage users
  • Manage groups
  • Manage computers


Manage users

  • Create a new user account
  • Reset a user password
  • Copy a user account
  • Move a user account
  • Set logon hours
  • Disable or enable a user account
  • Map a certificate to a user account
  • Change a user's primary group
  • Delete a user account


Create a new user account

Microsoft Windows Graphic

To create a new user account

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the folder in which you want to add a user account.

    Where?

    • Active Directory Users and Computers
    • domain node
    • folder
  3. Point to New, and then click User.
  4. In First name, type the user's first name.
  5. In Initials, type the user's initials.
  6. In Last name, type the user's last name.
  7. Modify Full name to add initials or reverse order of first and last names.
  8. In User logon name, type the user logon name, click the UPN suffix in the drop-down list, and then click Next.

    If the user will use a different name to log on to computers running Windows 95, Windows 98, or Windows NT, then you can change the user logon name as it appears in User logon name (pre-Windows 2000) to the different name.

  9. In Password and Confirm password, type the user's password, and then select the appropriate password options.

Notes

  • XOX
  • XOX
  • To add a user, you can also click Create a new user in the current container on the toolbar.
  • To add a user, you can also copy any previously created user account. For more information, see Related Topics.
  • A new user account with the same name as a previously deleted user account does not automatically assume the permissions and group memberships of the previously deleted account because the security ID (SID) for each account is unique. To duplicate a deleted user account, all permissions and memberships must be manually recreated.
  • For interoperability with other directory services, you can create an InetOrgPerson user object. To create a new inetOrgPerson, in step three, click InetOrgPerson instead of User. For more information about InetOrgPerson, see User and computer accounts in Related Topics.
  • When creating a new user, the full name attribute is created in the FirstName LastName format by default. The full name attribute also governs the display name format that is shown in the global address list. You can change the display name format by using ADSI Edit. If you do so, this will also change the full name format. For more information, see article Q250455, "How to Change Display Names of Active Directory Users" in the Microsoft Knowledge Base.
  • Windows NT 4.0 and earlier domains allow the use of a period (.) at the end of a user logon name as long as the user logon name does not consist solely of period characters. Windows Server 2003 domains do not allow the use of a period or multiple periods at the end of a user logon name.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsadd user UserDN [-samid SAMName] -pwd {Password|*}

Value | Description
UserDN | Specifies the distinguished name of the user object to be added.
SAMName | Specifies the Security Accounts Manager (SAM) name as the unique SAM account name for this user (for example, Linda). If not specified, dsadd will attempt to create the SAM account name using up to the first 20 characters from the common name (CN) value of UserDN.
Pwd | Specifies the password to be used for the user account. If set to *, you are prompted for a user password.

Notes

  • XOX
  • XOX
  • To add a user, you can also copy any previously created user account. For more information, see Related Topics.
  • A new user account with the same name as a previously deleted user account does not automatically assume the permissions and group memberships of the previously deleted account because the security ID (SID) for each account is unique. To duplicate a deleted user account, all permissions and memberships must be manually recreated.
  • To view the complete syntax for this command, and for information on entering more user account information, at a command prompt, type:

    dsadd user /?

Related Topics


Reset a user password

Microsoft Windows Graphic

To reset a user password

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. In the details pane, right-click the user whose password you want to reset, and then click Reset Password.
  4. Type and confirm the password.
  5. If you want to require the user to change this password at the next logon process, select the User must change password at next logon check box.

Notes

  • XOX
  • XOX
  • Services that are authenticated with a user account must be reset if the password for the service's user account is changed.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmod user UserDN -pwd NewPassword

  3. If you want to require the user to change this password at the next logon process, Type:

    4. dsmod user UserDN -mustchpwd {yes|no}

Value | Description
UserDN | Specifies the distinguished name of the user for which the password will be reset.
NewPassword | Specifies the password that will replace the current user password.

Notes

  • XOX
  • XOX
  • If a password is not assigned, then the first time the user tries to log on (using a blank password), a logon message will appear that says "You are required to change your password at first logon" and after user has changed the password, the logon process continues.
  • Services that are authenticated with a user account must be reset if the password for the service's user account is changed.
  • To view the complete syntax for this command, at a command prompt, type:

    dsmod user /?

Related Topics


Copy a user account

Microsoft Windows graphic

To copy a user account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. In the details pane, right-click the user account that you want to copy, and then click Copy.
  4. In First name, type the user's first name.
  5. In Last name, type the user's last name.
  6. Modify Full name to add initials or reverse order of first and last names.
  7. In User logon name, type the user logon name, click the UPN suffix in the drop-down list, and then click Next.

    If the user will use a different name to log on to computers running Windows 95, Windows 98, or Windows NT, then you can change the user logon name as it appears in User logon name (pre-Windows 2000) to the different name.

  8. In Password and Confirm password, type the user's password, and then select the appropriate password options.

    If the user account from which the new user account was copied was disabled, click Account is disabled to enable the new account.

Notes

  • XOX
  • XOX
  • After creating the user account, edit the user account properties to enter additional user account information.
  • Only the most commonly used attributes, such as logon hours, workstation restrictions, and account expiration restrictions are transferred to the copied user by default.
  • You can modify which default attributes are carried over to a newly copied user or specify additional attributes that will be copied to the new user. To do this, open the Active Directory Schema snap-in, view the desired attribute properties, and select (or clear) the Attribute is copied when duplicating user check box. You can only modify or add attributes that are instances of the user class. If the Active Directory Schema snap-in is not installed, see Related Topics.

Related Topics


Move a user account

Microsoft Windows graphic

To move a user account

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. In the details pane, right-click the user you want to move, and then click Move.
  4. In the Move dialog box, click the folder to which you want to move the user account.

Notes

  • XOX
  • XOX
  • You cannot use Active Directory Users and Computers to move user accounts between domains. To move a user account between domains, use Movetree, one of the Active Directory support tools. For more information, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmov UserDN [-newparent ParentDN] -pwd {Password|*}

Value | Description
UserDN | Specifies the distinguished name of the user object to be moved.
ParentDN | Specifies the new location to which you want to move the user object. The new location is specified as the distinguished name of the new parent node.
Pwd | Specifies to use either a password or a * to log on to a remote server. If you type *, then you are prompted for a password.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, and for information on entering more user account information, at a command prompt, type:

    dsmov /?

Related Topics


Set logon hours

Microsoft Windows graphic

To set logon hours

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. Right-click the user account, and then click Properties.
  4. On the Account tab, click Logon Hours, and then set the permitted or denied logon hours for the user.

Notes

  • XOX
  • XOX
  • To modify the logon hours for multiple users, press and hold down CTRL, and then click each user. Right-click the selected users, and then click Properties.

Related Topics


Disable or enable a user account

Microsoft Windows Graphic

To disable or enable a user account

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. In the details pane, right-click the user.
  4. Depending on the status of the account, do one of the following:
    • To disable, click Disable Account.
    • To enable, click Enable Account.

Notes

  • XOX
  • XOX
  • To prevent a particular user from logging on for security reasons, you can disable user accounts rather than deleting user accounts.
  • By creating disabled user accounts with common group memberships, you can use disabled user accounts as account templates to simplify user account creation. For more information, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmod user UserDN -disabled {yes|no}

Value | Description
UserDN | Specifies the distinguished name of the user object to be disabled or enabled.
{yes|no} | Specifies whether the user account is disabled for log on (yes) or not (no).

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dsmod user /?

  • To prevent a particular user from logging on for security reasons, you can disable user accounts rather than deleting user accounts.
  • By creating disabled user accounts with common group memberships, you can use disabled user accounts as account templates to simplify user account creation. For more information, see Related Topics.

Related Topics


Map a certificate to a user account

Microsoft Windows graphic

To map a certificate to a user account

  1. Open Active Directory Users and Computers.
  2. On the View menu, select Advanced Features.
  3. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  4. In the details pane, click the user account to which you want to map a certificate.
  5. On the Action menu, click Name Mappings.
  6. In the Security Identity Mapping dialog box, on the X.509 Certificates tab, click Add.
  7. Type the name and path of the .cer file that contains the certificate you want to map to this user account, and then click Open.
  8. Do one of the following:
    To | Do this
    Map the certificate to one account (one-to-one mapping) | Confirm that both the Use Issuer for alternate security identity and the Use Subject for alternate security identity check boxes are selected.
    Map any certificate that has the same subject to the user account, regardless of the issuer of the certificate (many-to-one mapping) | Clear the Use Issuer for alternate security identity check box, and confirm that the Use Subject for alternate security identity check box is selected.
    Map any certificate that has the same issuer to the user account, regardless of the subject of the certificate (many-to-one mapping) | Clear the Use Subject for alternate security identity check box, and confirm that the Use Issuer for alternate security identity check box is selected.

Notes

  • XOX
  • XOX
  • The certificate you are mapping to a user account must be in Distinguished Encoding Rules (DER) or Base64 encoded binary format. For instructions on exporting an existing certificate to a .cer file, see Related Topics.

Related Topics


Change a user's primary group

Microsoft Windows graphic

To change a user's primary group

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. In the details pane, right-click the user you want to change, and then click Properties.
  4. On the Member of tab, click the group that you want to set as the user's primary group, and then click Set Primary Group.

Notes

  • XOX
  • XOX
  • The user's primary group applies only to users who log on to the network through Services for Macintosh or to who run POSIX-compliant applications. Unless you are using these services, there is no need to change the primary group from Domain Users, which is the default value.
  • Setting the user's primary group membership to a value other than Domain Users may adversely impact performance as all users in the domain are members of Domain Users. If the user's primary group is set to another group, it may cause the group membership to exceed the supported maximum number of members.

Related Topics


Delete a user account

Microsoft Windows Graphic

To delete a user account

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. In the details pane, right-click the user account, and then click Delete.

Notes

  • XOX
  • XOX
  • Once a user account has been deleted, all permissions and memberships associated with that user account are permanently deleted. Because the security ID (SID) for each account is unique, a new user account with the same name as a previously deleted user account does not automatically assume the permissions and memberships of the previously deleted account. To duplicate a deleted user account, all permissions and memberships must be manually recreated.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsrm ObjectDN

Value | Description
ObjectDN | Specifies the distinguished name of the user object to be deleted.

Notes

  • XOX
  • XOX
  • Once a user account has been deleted, all permissions and memberships associated with that user account are permanently deleted. Because the security ID (SID) for each account is unique, a new user account with the same name as a previously deleted user account does not automatically assume the permissions and memberships of the previously deleted account. To duplicate a deleted user account, all permissions and memberships must be manually recreated.
  • To view the complete syntax for this command, at a command prompt, type:

    dsrm /?

Related Topics


Manage groups

  • Create a new group
  • Add a member to a group
  • Allow anonymous users to be members of the Everyone security group on a domain controller
  • Convert a group to another group type
  • Change group scope
  • Delete a group
  • Find groups in which a user is a member
  • Assign user rights to a group in Active Directory


Create a new group

Microsoft Windows Graphic

To create a new group

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the folder in which you want to add a new group.

    Where?

    • Active Directory Users and Computers
    • domain node
    • folder
  3. Point to New, and then click Group.
  4. Type the name of the new group.

    By default, the name you type is also entered as the pre-Windows 2000 name of the new group.

  5. In Group scope, click one of the options.
  6. In Group type, click one of the options.

Notes

  • XOX
  • XOX
  • To add a group, you can also click the folder in which you want to add the group, and then click Create a new group in the current container. on the toolbar.
  • If the domain in which you are creating the group is set to the domain functional level of Windows 2000 mixed, you can select only the Security group type with Domain local or Global scopes. For more information, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsadd group GroupDN -samid SAMName -secgrp yes | no -scope l | g | u

Value | Description
GroupDN | Specifies the distinguished name of the group object that you want to add.
SAMName | Specifies to use the Security Accounts Manager (SAM) name as the unique SAM account name for this group (for example, operators).
yes | no | Specifies whether the group you want to add is a security group (yes) or a distribution group (no).
l | g | u | Specifies whether the scope of the group you want to add is domain local (l), global (g), or universal (u).

Notes

  • XOX
  • XOX
  • If the domain in which you are creating the group is set to the domain functional level of Windows 2000 mixed, you can select only the Security group type with Domain local or Global scopes. For more information, see Related Topics.
  • To view the complete syntax for this command, at a command prompt, type:

    dsadd group /?

Related Topics


Add a member to a group

Microsoft Windows Graphic

To add a member to a group

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click the folder that contains the group to which you want to add a member.

    Where?

    • Active Directory Users and Computers
    • domain node
    • folder that contains the group
  3. In the details pane, right-click the group, and then click Properties.
  4. On the Members tab, click Add.
  5. In Enter the object names to select, type the name of the user, group, or computer that you want to add to the group, and then click OK.

Notes

  • XOX
  • XOX
  • In addition to users and computers, membership in a particular group can include contacts and other groups.
  • To add members to a group, you can click the members you want to add, click Adds the selected objects to a group you specify. on the toolbar, and then type the name of the group into which they will be added. You can also drag a member object to a group, or right-click the object, and then click Add to a group.
  • When you administer a domain, security principals in the parent domain or other trusted domains are not visible on the Member Of tab of a domain users properties. The only domain accounts that you can add or view are the present domain groups. Only domain groups in the present domain are shown, even if the member belongs to other trusted domain groups.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmod group GroupDN -addmbr MemberDN

Value | Description
GroupDN | Specifies the distinguished name of the group object to which you want to add the object.
MemberDN | Specifies the distinguished name of the object that you want to add to the group.

Notes

  • XOX
  • XOX
  • In addition to users and computers, a group can contain contacts and other groups.
  • To view the complete syntax for this command, at a command prompt, type:

    dsmod group /?

Related Topics


Allow members of the Anonymous Logon group to be members of the Everyone group on a domain controller

Microsoft Windows Graphic

To allow members of the Anonymous Logon group to be members of the Everyone group on a domain controller

  1. Click Start, point to Programs, point to Administrative Tools, and then click Domain Security Policy.
  2. In the console tree, click Security Options.

    Where?

    • Default Domain Controller Policy
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Local Policies
    • Security Options
  3. In the details pane, right-click Network access: Let Everyone permissions apply to anonymous users, and then click Properties.
  4. Select the Define this policy setting check box, and then click Enabled.

Note

  • By default, members of the Anonymous Logon group are not included in the Everyone group.

Related Topics


Convert a group to another group type

Microsoft Windows Graphic

To convert a group to another group type

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click the folder that contains the group that you want to convert to another group type.

    Where?

    • Active Directory Users and Computers
    • domain node
    • folder that contains the group
  3. In the details pane, right-click the group, and then click Properties.
  4. On the General tab, under Group type, click the group type.

Notes

  • XOX
  • XOX
  • To convert a group, the domain functional level must be set to Windows 2000 native or higher. Groups cannot be converted when the domain functional level is set to Windows 2000 mixed.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmod group GroupDN -secgrp {yes|no}

Value | Description
GroupDN | Specifies the distinguished name of the group object for which you want to change the group type.
{yes|no} | Specifies that the group type is set to security group (yes) or distribution group (no).

Notes

  • XOX
  • XOX
  • To convert a group, the domain functional level must be set to Windows 2000 native or higher. Groups cannot be converted when the domain functional level is set to Windows 2000 mixed.
  • To view the complete syntax for this command, at a command prompt, type:

    dsmod group /?

Related Topics


Change group scope

Microsoft Windows Graphic

To change group scope

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click the folder that contains the group for which you want to change the group scope.

    Where?

    • Active Directory Users and Computers
    • domain node
    • folder that contains the group
  3. In the details pane, right-click the group, and then click Properties.
  4. On the General tab, under Group scope, click the group scope.

Notes

  • XOX
  • XOX
  • You can only change group scopes when the domain functional level is set to Windows 2000 native or higher.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmod group GroupDN -scope L|G|U

Value | Description
GroupDN | Specifies the distinguished names (DNs) of the group object to which the scope will be changed.
L|G|U | Specifies that the scope of the group be set to local, global or universal. If the domain is still in Windows 2000 mixed, then the universal scope will not be supported. Also, it is not possible to convert a domain local group to global group or vice versa.

Notes

  • XOX
  • XOX
  • You can only change group scopes when domain functional level is set to Windows 2000 native or higher.
  • To view the complete syntax for this command, at a command prompt, type:

    dsmod group /?

Related Topics


Delete a group

Microsoft Windows Graphic

To delete a group

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click the folder that contains the group you want to delete.

    Where?

    • Active Directory Users and Computers
    • domain node
    • folder that contains the group
  3. In the details pane, right-click the group, and then click Delete.

Notes

  • XOX
  • XOX
  • Deleting a group is a permanent operation.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsrm GroupDN

Value | Description
GroupDN | Specifies the distinguished name of the group object to be deleted.

Notes

  • XOX
  • XOX
  • Deleting a group is a permanent operation.
  • To view the complete syntax for this command, at a command prompt, type:

    dsrm /?

Related Topics


Find groups in which a user is a member

Microsoft Windows Graphic

To find groups in which a user is a member

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. In the details pane, right-click a user account, and then click Properties.
  4. Click the Member Of tab.

Notes

  • XOX
  • XOX
  • The Member Of tab for a user displays a list of groups in the domain where the user's account is located. Active Directory does not display groups that reside in trusted domains where the user is a member.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsget user UserDN -memberof

Value | Description
UserDN | Specifies the distinguished name of the user object for which you want to display group membership.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dsget user /?

Related Topics


Assign user rights to a group in Active Directory

Microsoft Windows Graphic

To assign user rights to a group in Active Directory

  1. Open Domain Controller Security Policy.
  2. In the console tree, click User Rights Assignment.

    3. Where?

    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Local Policies
    • User Rights Assignment
  3. In the details pane, double-click the user right that you want to assign.
  4. Click Add User or Group.

    If the button appears dimmed, select the Define these policy settings check box.

  5. Type the name of the group to which you want to assign this right.

Notes

  • XOX
  • XOX

Related Topics


Manage computers

  • Create a new computer account
  • Add a computer account to a group
  • Delete a computer account
  • Manage a remote computer
  • Move a computer account
  • Reset a computer account
  • Disable or enable a computer account


Create a new computer account

Microsoft Windows Graphic

To create a new computer account

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, right-click the folder in which you want to add the computer.

  3. Point to New, and then click Computer.
  4. Type the computer name.

Notes

  • XOX
  • XOX
  • By default, members of the Account Operators group can create computer accounts in the Computers container and in new organizational units.
  • By default, Authenticated Users in a domain are assigned the Add workstations to a domain user right and can create up to 10 computer accounts in the domain. For more information, see Related Topics.
  • There are two additional ways to give a user or group permission to add a computer to the domain: Use a Group Policy object to assign the Add Computer User permission, or, on the organizational unit, assign the user or group the Create Computer Objects permission.
  • XOX
  • If the computer using the account you are creating is a pre-Windows 2000 computer, select the Assign this computer account as a pre-Windows 2000 computer check box.
  • If the computer using the account you are creating is a Windows NT backup domain controller, select Assign this computer account as a backup domain controller check box.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsadd computer ComputerDN

Value | Description
ComputerDN | Specifies the distinguished name of the computer you want to add. The distinguished name specifies the directory location.

Notes

  • XOX
  • XOX
  • By default, members of the Account Operators group can create computer accounts in the Computers container and in new organizational units.
  • By default, Authenticated Users in a domain are assigned the Add workstations to a domain user right and can create up to 10 computer accounts in the domain. For more information, see Related Topics.
  • There are two additional ways to give a user or group permission to add a computer to the domain: Use a Group Policy object to assign the Add Computer User permission, or, on the organizational unit, assign the user or group the Create Computer Objects permission.

  • To view the complete syntax for this command, at a command prompt, type:

    dsadd computer /?

  • To modify the properties of a computer account, use the dsmod computer command.

Related Topics


Add a computer account to a group

Microsoft Windows Graphic

To add a computer account to a group

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the folder in which the computer is located.

  3. In the details pane, right-click the computer, and then click Properties.
  4. On the Member Of tab, click Add.
  5. In Enter the object names to select, type the name of a group that you want this computer to be a member of, and then click OK.

Notes

  • XOX
  • XOX
  • When viewing users, computers, and groups as containers, you can add a computer to a group by dragging it onto the desired group. For more information about view options in Active Directory Users and Computers, see Related Topics.
  • By adding a computer to a group, you can assign permissions to all of the computer accounts in that group and filter Group Policy settings on all accounts in that group.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmod group GroupDN -addmbr ComputerDN

Value | Description
GroupDN | Specifies the distinguished names of the group object to which you want to add the computer object.
ComputerDN | Specifies the distinguished name of the computer object to be added to the group. The distinguished name specifies the directory location.

Notes

  • XOX
  • XOX
  • By adding a computer to a group, you can assign permissions to all of the computer accounts in that group and filter Group Policy settings on all accounts in that group.
  • To view the complete syntax for this command, at a command prompt, type:

    dsmod group /?

Related Topics


Delete a computer account

Microsoft Windows graphic

To delete a computer account

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the folder in which the computer is located.

  3. In the details pane, right-click the computer, and then click Delete.

Notes

  • XOX
  • XOX
  • You can also delete a computer account by disjoining the computer from the domain.
  • Once a computer account has been deleted, all permissions and memberships associated with that computer account are permanently deleted. Because the security ID (SID) for each account is unique, a new computer account with the same name as a previously deleted computer account does not inherit the permissions and memberships of the previously deleted account. To duplicate a deleted computer account, all permissions and memberships must be manually recreated.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsrm computer ComputerDN

Value | Description
ComputerDN | Specifies the distinguished name of the computer you want to add. The distinguished name specifies the directory location.

Notes

  • XOX
  • XOX
  • You can also delete a computer account by disjoining the computer from the domain.
  • Once a computer account has been deleted, all permissions and memberships associated with that computer account are permanently deleted. Because the security ID (SID) for each account is unique, a new computer account with the same name as a previously deleted computer account does not inherit the permissions and memberships of the previously deleted account. To duplicate a deleted computer account, all permissions and memberships must be manually recreated.

  • To view the complete syntax for this command, at a command prompt, type:

    dsrm computer /?

Related Topics


Manage a remote computer

Microsoft Windows graphic

To manage a remote computer

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the folder that contains the computer you want to manage.

  3. In the details pane, right-click the computer, and then click Manage.

Notes

  • XOX
  • XOX
  • Clicking Manage starts Computer Management from which you can administer remote computers. You must have administrative credentials on the local computer to view certain information or to modify computer properties using Computer Management.

Related Topics


Move a computer account

Microsoft Windows graphic

To move a computer account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the folder that contains the computer that you want to move.

  3. In the details pane, right-click the computer, and then click Move.
  4. In the Move dialog box, click the domain node.
  5. Click the folder to which you want to move the computer, and then click OK.

Notes

  • XOX
  • XOX
  • You cannot use Active Directory Users and Computers to move computer accounts between domains. To move a computer account between domains, use Movetree, one of the Active Directory support tools. For more information, see Related Topics.
  • Members of the Account Operators group can move computer accounts to organizational units but not to default containers, such as Builtin or Computers. However, Account Operators cannot move computer accounts into the Domain Controllers organizational unit but can move computer accounts from the Domain Controllers organizational unit.

Related Topics


Reset a computer account

Microsoft Windows Graphic

To reset a computer account

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the folder that contains the computer that you want to reset.

  3. In the details pane, right-click the computer, and then click Reset Account.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmod computer ComputerDN -reset

Value | Description
ComputerDN | Specifies the distinguished names of one or more computer objects that you want to reset.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dsmod computer /?

Related Topics


Disable or enable a computer account

Microsoft Windows Graphic

To disable or enable a computer account

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Computers.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Computers

    Or, click the folder that contains the computer that you want to enable or disable.

  3. In the details pane, right-click the desired computer, and then do one of the following:
    • To disable, click Disable Account.
    • To enable, click Enable Account.

Notes

  • XOX
  • XOX
  • When you disable a computer account, the computer cannot authenticate to the domain until it has been enabled.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmod computer ComputerDN -disabled {yes|no}

Value | Description
ComputerDN | Specifies the distinguished names of the computer object that you want to disable or enable.
{yes|no} | Specifies whether the computer is disabled for log on (yes) or not (no).

Notes

  • XOX
  • XOX
  • When you disable a computer account, the computer cannot authenticate to the domain until it has been enabled.
  • To view the complete syntax for this command, at a command prompt, type:

    dsmod computer /?

Related Topics


Publish resources

  • Publish a shared folder
  • Manually publish a printer in Active Directory


Publish a shared folder

Microsoft Windows graphic

To publish a shared folder

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the folder in which you want to add a shared folder.

    Where?

    • Active Directory Users and Computers
    • domain node
    • folder
  3. Point to New, and then click Shared Folder.
  4. Type the name of the folder and the network path.

Notes

  • XOX
  • XOX

Related Topics


Manage domains

  • Create a new forest
  • Create a new domain tree
  • Create a new child domain
  • Manage a different domain
  • Remove a domain
  • Manage the domain using a different domain controller
  • Add user principal name suffixes
  • Delete extinct domain metadata
  • Raise the domain functional level
  • Assign, change, or remove permissions on Active Directory objects or attributes
  • Manage organizational units
  • Manage domain controllers


Create a new forest

Microsoft Windows Graphic

To create a new forest

  1. Click Start, click Run, and then type dcpromo to start the Active Directory Installation Wizard.
  2. On the Operating System Compatibility page, read the information and then click Next.

    If this is the first time you have installed Active Directory on a server running Windows Server 2003, click Compatibility Help for more information.

  3. On the Domain Controller Type page, click Domain controller for a new domain, and then click Next.
  4. On the Create New Domain page, click Domain in a new forest, and then click Next.
  5. On the New Domain Name page, type the full DNS name for the new domain, and then click Next.
  6. On the NetBIOS Domain Name page, verify the NetBIOS name, and then click Next.
  7. On the Database and Log Folders page, type the location in which you want to install the database and log folders, or click Browse to choose a location, and then click Next.
  8. On the Shared System Volume page, type the location in which you want to install the Sysvol folder, or click Browse to choose a location, and then click Next.
  9. On the DNS Registration Diagnostics page, verify if an existing DNS server will be authoritative for this forest or, if necessary, choose to install and configure DNS on this server by clicking Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server, and then click Next.
  10. On the Permissions page, select one of the following:
    • Permissions compatible with pre-Windows 2000 server operating systems
    • Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems
  11. Review the Summary page, and then click Next to begin the installation.
  12. Restart the computer.

Notes

  • XOX
  • The server on which you install Active Directory using this procedure will be the first domain controller in the forest root domain.
  • Before installing Active Directory, you will need to consider pre-Windows 2000 compatible security levels and identify the DNS name of the domain. For more information, see the checklist in Related Topics.
  • The wizard options on the Permissions page affect application compatibility with computers running pre-Windows 2000 and Windows Server 2003 operating systems and are not related to domain functionality. For more information about permissions, see Related Topics.
  • The Active Directory Installation Wizard allows Active Directory domain names up to 64 characters or up to 155 bytes. Although the limit of 64 characters is usually reached before the limit of 155 bytes, the opposite could be true if the name contains Unicode characters consuming three bytes. These limits do not apply to computer names.
  • You cannot install Active Directory on a computer running XOX, but you can join the computer to an Active Directory domain as a member server. For more information about XOX, see Related Topics.

Related Topics


Create a new domain tree

Microsoft Windows Graphic

To create a new domain tree

  1. Click Start, click Run, and then type dcpromo to start the Active Directory Installation Wizard.
  2. On the Operating System Compatibility page, read the information and then click Next.

    If this is the first time you have installed Active Directory on a server running Windows Server 2003, click Compatibility Help for more information.

  3. On the Domain Controller Type page, click Domain controller for a new domain, and then click Next.
  4. On the Create New Domain page, click Domain tree in an existing forest.
  5. On the Network Credentials page, type the user name, password, and user domain of the user account you want to use for this operation, and then click Next.

    The user account must be a member of the Enterprise Admins group.

  6. On the New Domain Tree page, type the full DNS name for the new domain, and then click Next.
  7. On the NetBIOS Domain Name page, verify the NetBIOS name, and then click Next.
  8. On the Database and Log Folders page, type the location in which to install the database and log folders, or click Browse to choose a location, and then click Next.
  9. On the Shared System Volume page, type the location in which to install the Sysvol folder, or click Browse to choose a location, and then click Next.
  10. On the DNS Registration Diagnostics page, verify if an existing DNS server will be authoritative for this forest or, if necessary, choose to install and configure DNS on this server by clicking Install and configure the DNS server on this computer, and set this computer to use this DNS server as its preferred DNS server, and then click Next.
  11. On the Permissions page, select one of the following:
    • Permissions compatible with pre-Windows 2000 server operating systems
    • Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems
  12. On the Directory Services Restore Mode Administrator Password page, type and confirm the password that you want to assign to the Administrator account for this server, and then click Next.

    Use this password when starting the computer in Directory Services Restore Mode.

  13. Review the Summary page, and then click Next to begin the installation.
  14. Restart the computer.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • The server on which you install Active Directory using this procedure will be the first domain controller in a new domain tree.
  • Before installing Active Directory, you will need to consider pre-Windows 2000 compatible security levels and identify the DNS name of the domain. For more information, see the checklist in Related Topics.
  • When a new domain tree is created in an existing forest, a two-way, transitive tree root trust is established by default.
  • The wizard options on the Permissions page affect application compatibility with computers running pre-Windows 2000 and Windows Server 2003 operating systems and are not related to domain functionality. For more information about permissions, see Related Topics.
  • You can also use a smart card to verify administrative credentials. For more information about smart cards, see Related Topics.
  • The Active Directory Installation Wizard allows Active Directory domain names up to 64 characters or up to 155 bytes. Although the limit of 64 characters is usually reached before the limit of 155 bytes, the opposite could be true if the name contains Unicode characters consuming three bytes. These limits do not apply to computer names.
  • You cannot install Active Directory on a computer running XOX, but you can join the computer to an Active Directory domain as a member server. For more information about XOX, see Related Topics.

Related Topics


Create a new child domain

Microsoft Windows Graphic

To create a new child domain

  1. Click Start, click Run, and then type dcpromo to start the Active Directory Installation Wizard.
  2. On the Operating System Compatibility page, read the information and then click Next.

    If this is the first time you have installed Active Directory on a server running Windows Server 2003, click Compatibility Help for more information.

  3. On the Domain Controller Type page, click Domain controller for a new domain, and then click Next.
  4. On the Create New Domain page, click Child domain in an existing domain tree, and then click Next.
  5. On the Network Credentials page, type the user name, password, and user domain of the user account you want to use for this operation, and then click Next.

    The user account must be a member of the Enterprise Admins group.

  6. On the Child Domain Installation page, verify the parent domain and type the new child domain name, and then click Next.
  7. On the NetBIOS Domain Name page, verify the NetBIOS name, and click Next.
  8. On the Database and Log Folders page, type the location in which you want to install the database and log folders, or click Browse to choose a location, and then click Next.
  9. On the Shared System Volume page, type the location in which you want to install the Sysvol folder, or click Browse to choose a location, and then click Next.
  10. On the DNS Registration Diagnostics page, verify the DNS configuration settings are accurate, and then click Next.
  11. On the Permissions page, select one of the following:
    • Permissions compatible with pre-Windows 2000 server operating systems
    • Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems
  12. On the Directory Services Restore Mode Administrator Password page, type and confirm the password that you want to assign to the Administrator account for this server, and then click Next.

    Use this password when starting the computer in Directory Services Restore Mode.

  13. Review the Summary page, and then click Next to begin the installation.
  14. Restart the computer.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the parent domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • The server on which you install Active Directory using this procedure will be the first domain controller in a new child domain.
  • Before installing Active Directory, you will need to consider pre-Windows 2000 compatible security levels and identify the DNS name of the domain. For more information, see the checklist in Related Topics.
  • When a child domain is added to an existing tree domain, a two-way, transitive parent and child trust is established by default.
  • The wizard options on the Permissions page affect application compatibility with computers running pre-Windows 2000 and Windows Server 2003 operating systems and are not related to domain functionality. For more information about permissions, see Related Topics.
  • You can also use a smart card to verify administrative credentials. For more information about smart cards, see Related Topics.
  • The Active Directory Installation Wizard allows Active Directory domain names up to 64 characters or up to 155 bytes. Although the limit of 64 characters is usually reached before the limit of 155 bytes, the opposite could be true if the name contains Unicode characters consuming three bytes. These limits do not apply to computer names.
  • You cannot install Active Directory on a computer running XOX, but you can join the computer to an Active Directory domain as a member server. For more information about XOX, see Related Topics.

Related Topics


Manage a different domain

Microsoft Windows graphic

To manage a different domain

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Active Directory Users and Computers, and then click Connect to Domain.

  3. Type the domain name.

    Or, click Browse, and then select a domain from the list.

Notes

  • XOX However, you must have the appropriate administrative credentials to manage the domain you select.
  • XOX
  • If you select the Save this domain setting for the current console option, Active Directory Users and Computers will attempt to connect to the domain each time it is opened.
  • The domain name includes all of the domain's parent domains. For example, the domain widgets could have a full name of widgets.microsoft.com.

Related Topics


Remove a domain

Microsoft Windows graphic

To remove a domain

  1. On the last domain controller in the domain, click Start, and then click Run.
  2. In Open, type dcpromo to open the Active Directory Installation Wizard, and then click Next.
  3. On the Remove Active Directory page, select the This server is the last domain controller in the domain check box, and then continue to follow the wizard.

Caution

  • Removing a domain will result in the permanent loss of any data contained in that domain. This includes all user, group, and computer accounts.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • To remove an Active Directory domain, you must first demote all other domain controllers associated with the domain. For information about demoting domain controllers, see Related Topics.
  • If the domain has child domains, it cannot be deleted.
  • If this is the last domain in the forest, demoting this domain controller will also delete the forest.
  • If the domain controller currently holds the domain naming master or schema master operations roles, transfer the role to domain controller in a different domain before removing the domain. For information about locating operations masters and transferring operations master roles, see Related Topics.
  • If the domain controller holds the last replica of one or more application directory partitions, you must first remove the last application directory partition replicas from the domain controller before you can delete the domain. You can use the Active Directory Installation Wizard to remove all application directory partition replicas from the domain controller or you can manually remove the partitions using the Ntdsutil command-line tool. For information about application directory partitions, see Related Topics.

Related Topics


Manage the domain using a different domain controller

Microsoft Windows graphic

To manage the domain using a different domain controller

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Active Directory Users and Computers, and then click Connect to Domain Controller.

  3. Click a domain controller in the list.

    Or, in Enter the name of another domain controller, type the name of a domain controller.

Notes

  • XOX However, you must have the appropriate administrative credentials to manage the domain you select.
  • XOX
  • By default, domain controllers are created in the Domain Controllers organizational unit when they are first configured.

Related Topics


Add user principal name suffixes

Microsoft Windows graphic

To add user principal name suffixes

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click Active Directory Domains and Trusts, and then click Properties.
  3. On the UPN Suffixes tab, type an alternative UPN suffix for the forest, and then click Add.
  4. Repeat step 3 to add additional alternative user principal name suffixes.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority.
  • XOX
  • UPN suffixes should conform to DNS conventions for valid characters and syntax.

Related Topics


Delete extinct domain metadata

Microsoft Windows graphic

To delete extinct domain metadata

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command, type:

    4. metadata cleanup

  4. At the metadata cleanup command, type:

    5. connection

  5. At the connection command, type:

    6. connect to server Server

  6. At the connection command, type:

    7. quit

  7. At the metadata cleanup command, type:

    8. select operation target

  8. At the select operation target command, type:

    9. list sites

  9. A numbered list of sites will be displayed, type:

    10. select site SiteNumber

  10. At the select operation target command, type:

    11. list domains in site

  11. A numbered list of domains in the selected site will be displayed, type:

    12. select domain DomainNumber

    quit

  12. At the metadata cleanup command, type:

    13. remove selected domain

Value | Description
Server | The DNS name of a domain controller.
SiteNumber | The number in the displayed list that corresponds to the site that you want to connect to.
DomainNumber | The number in the displayed list that corresponds to the domain that you want to clean up.

Notes

  • XOX
  • To clean metadata you must first select the operation target. When selecting the operation target for a server, you must first select the site and then the domain.

Related Topics


Raise the domain functional level

Microsoft Windows graphic

To raise the domain functional level

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain for which you want to raise functionality, and then click Raise Domain Functional Level.
  3. In Select an available domain functional level, do one of the following:
    • To raise the domain functional level to Windows 2000 native, click Windows 2000 native, and then click Raise.
    • To raise domain functional level to Windows Server 2003, click Windows Server 2003, and then click Raise.

Caution

  • If you have or will have any domain controllers running Windows NT 4.0 and earlier, then do not raise the domain functional level to Windows 2000 native. Once the domain functional level is set to Windows 2000 native, it cannot be changed back to Windows 2000 mixed.

    If you have or will have any domain controllers running Windows NT 4.0 and earlier or Windows 2000, then do not raise the domain functional level to Windows Server 2003. Once the domain functional level is set to Windows Server 2003, it cannot be changed back to Windows 2000 mixed or Windows 2000 native.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group in the domain for which you want to raise functionality or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • You can also raise the domain functional level by right-clicking a domain displayed in Active Directory Users and Computers, and then clicking Raise Domain Functional Level.
  • The current domain functional level is displayed under Current domain functional level in the Raise Domain Functional Level dialog box.

Related Topics


Assign, change, or remove permissions on Active Directory objects or attributes

Microsoft Windows graphic

To assign, change, or remove permissions on Active Directory objects or attributes

  1. Open Active Directory Users and Computers.
  2. On the View menu, select Advanced Features.
  3. Right-click the object for which you want to assign, change, or remove permissions, and then click Properties.
  4. On the Security tab, click Advanced to view all of the permission entries that exist for the object.
  5. Do one or more of the following:
    • To assign new permissions on an object or attribute, click Add. Type the name of the group, computer, or user that you want to add, and then click OK. In the Permission Entry for ObjectName dialog box, on the Object and Properties tabs, select or clear the Allow or Deny check boxes, as appropriate.
    • To change existing permissions on an object or attribute, click a permission entry, and then click Edit. On the Object and Properties tabs, select or clear the Allow or Deny check boxes, as appropriate.
    • To remove existing permissions from an object or attribute, click a permission entry, and then click Remove.

Important

  • Before adding access control permissions on Active Directory objects or properties, see Related Topics.

Notes

  • XOX
  • XOX

Related Topics


Manage organizational units

  • Create a new organizational unit
  • Delegate control of an organizational unit
  • Delete an organizational unit
  • Move an organizational unit


Create a new organizational unit

Microsoft Windows Graphic

To create a new organizational unit

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the folder in which you want to add an organizational unit.

    Where?

    • Active Directory Users and Computers
    • domain node
    • folder
  3. Point to New, and then click Organizational Unit.
  4. Type the name of the organizational unit.

Notes

  • XOX
  • XOX
  • To add an organizational unit, you can also click the domain node or folder in which you want to add the organizational unit, and then click Create a new organizational unit in the current container. on the toolbar.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsadd ou OrganizationalUnitDN

Value | Description
OrganizationalUnitDN | Specifies the distinguished name of the organizational unit to be added.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dsadd ou /?

  • To modify the properties of an organizational unit, use the dsmod ou command.

Related Topics


Delegate control of an organizational unit

Microsoft Windows graphic

To delegate control of an organizational unit

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the organizational unit for which you want to delegate control.

    Where?

    • Active Directory Users and Computers
    • domain node
    • organizational unit
  3. Click Delegate control to start the Delegation of Control Wizard, and then follow the instructions.

Notes

  • XOX
  • XOX

Related Topics


Delete an organizational unit

Microsoft Windows Graphic

To delete an organizational unit

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the organizational unit in which you want to delete.

    Where?

    • Active Directory Users and Computers
    • domain node
    • organizational unit
  3. Click Delete.

Notes

  • XOX
  • XOX
  • If the selected organizational unit contains other objects, Active Directory Users and Computers prompts you to either continue or cancel the deletion. If you continue the deletion, all objects within the organizational unit will also be deleted.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsrm OrganizationalUnitDN

Value | Description
OrganizationalUnitDN | Specifies the distinguished name of the organizational unit to be deleted.

Notes

  • XOX
  • XOX
  • Attempting to delete an organizational unit containing other objects will result in an error, unless the -subtree option is used. With the -subtree option, dsrm deletes both the selected organizational unit and any objects it contains.
  • To view the complete syntax for this command, at a command prompt, type:

    dsrm /?

    or see Related Topics.

Related Topics


Move an organizational unit

Microsoft Windows graphic

To move an organizational unit

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the organizational unit that you want to move.

    Where?

    • Active Directory Users and Computers
    • domain node
    • organizational unit
  3. Click Move, and then click the folder to which you want to move the organizational unit.

Notes

  • XOX
  • XOX
  • Active Directory Users and Computers can only move organizational units within the same domain. To move organizational units between domains, use Movetree. For more information about Movetree and other Active Directory support tools, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmov OuDN [-newparent ParentDN] -pwd {Password|*}

Value | Description
OuDN | Specifies the distinguished name of the organizational unit object to be moved.
ParentDN | Specifies the new location to which you want to move the organizational unit object. The new location is specified as the distinguished name of the new parent node.
Pwd | Specifies to use either a password or a * to log on to a remote server. If you type *, then you are prompted for a password.

Notes

  • XOX
  • Active Directory Users and Computers can only move organizational units within the same domain. To move organizational units between domains, use Movetree. For more information about Movetree and other Active Directory support tools, see Related Topics.

Related Topics


Manage domain controllers

  • Create an additional domain controller
  • Demote a domain controller
  • Rename a domain controller
  • Disable signed or encrypted LDAP traffic


Create an additional domain controller

Microsoft Windows graphic

To create an additional domain controller

  1. Click Start, click Run, and then type dcpromo /adv to open the Active Directory Installation Wizard with the option to create an additional domain controller from restored backup files.
  2. On the Operating System Compatibility page, read the information and then click Next.

    If this is the first time you have installed Active Directory on a server running Windows Server 2003, click Compatibility Help for more information.

  3. On the Domain Controller Type page, click Additional domain controller for an existing domain, and then click Next.
  4. On the Copying Domain Information page, do one of the following:
    • Click Over the network, and then click Next.
    • Click From these restored backup files, and type the location of the restored backup files, or click Browse to locate the restored files, and then click Next.
  5. On the Network Credentials page, type the user name, password, and user domain of the user account you want to use for this operation, and then click Next.

    The user account must be a member of the Domain Admins group for the target domain.

  6. On the Database and Log Folders page, type the location in which you want to install the database and log folders, or click Browse to choose a location, and then click Next.
  7. On the Shared System Volume page, type the location in which you want to install the Sysvol folder, or click Browse to choose a location, and then click Next.
  8. On the Directory Services Restore Mode Administrator Password page, type and confirm the password that you want to assign to the Administrator account for this server, and then click Next.

    Use this password when starting the computer in Directory Services Restore Mode.

  9. Review the Summary page, and then click Next to begin the installation.
  10. Restart the computer.

Notes

  • XOX
  • The /adv switch is only necessary when you want to create a domain controller from restored backup files. It is not required when creating an additional domain controller over the network.
  • In step 3, when choosing the option to copy domain information over the network, all directory data for the domain in which this domain controller will be a member will be copied over your network connection. You will have the option to cancel non-critical replication, if necessary.
  • In step 3, when choosing the option to copy domain information from restored backup files, you will need to first back up the System State data of a domain controller running Windows Server 2003 from the domain in which this member server will become an additional domain controller. Then, the System State backup must be restored locally on the server on which you are installing Active Directory. To do this using Backup, choose the option Restore files to: Alternate location. For more information about restoring backups, see Related Topics.
  • If a domain controller that was backed up contained an application directory partition, the application directory partition will not be restored on the new domain controller. For information about how to manually create an application directory partition on a new domain controller, see Related Topics.
  • If the domain controller from which you restored the System State data was a global catalog, you will have the option to make this new domain controller a global catalog.
  • You can also use a smart card to verify administrative credentials. For more information about smart cards, see Related Topics.
  • You cannot install Active Directory on a computer running XOX, but you can join the computer to an Active Directory domain as a member server. For more information about XOX, see Related Topics.

Related Topics


Demote a domain controller

Microsoft Windows graphic

To demote a domain controller

  1. On a domain controller, click Start, and then click Run.
  2. In Open, type dcpromo to open the Active Directory Installation Wizard, and then click Next.
  3. On the Remove Active Directory page, click Next, and then continue to follow the wizard.

Caution

  • Before you complete this procedure, verify that this domain controller is not the only global catalog and that it does not hold an operations master role.

Notes

  • XOX
  • If this domain controller is a global catalog, ensure that another global catalog is available to users before demoting it. For information about configuring domain controllers to host the global catalog, see Related Topics.
  • If this domain controller currently holds one or more operations master roles, transfer the operations master roles to another domain controller before demoting it. For information about locating operations masters and transferring operations master roles, see Related Topics.
  • If this domain controller is the last domain controller in the domain, demoting this domain controller will remove this domain from the forest. If this is the last domain in the forest, demoting this domain controller will also delete the forest. For information about removing domains and forests, see Related Topics.
  • If this domain controller holds the last replica of one or more application directory partitions, you must first remove the last application directory partition replicas from this domain controller before you can demote it. You can use the Active Directory Installation Wizard to remove all application directory partition replicas from this domain controller or you can manually remove them using the Ntdsutil command-line tool. For information about application directory partitions, see Related Topics.

Related Topics


Rename a domain controller

Microsoft Windows Graphic

To rename a domain controller

  1. Open Command Prompt.
  2. Type:

    netdom computername CurrentComputerName /add:NewComputerName

    3. This command will update the service principal name (SPN) attributes in Active Directory for this computer account and register DNS resource records for the new computer name. The SPN value of the computer account must be replicated to all domain controllers for the domain and the DNS resource records for the new computer name must be distributed to all the authoritative DNS servers for the domain name. If the updates and registrations have not occurred prior to removing the old computer name, then some clients may be unable to locate this computer using the new or old name.

  3. Ensure the computer account updates and DNS registrations are completed, then type:

    4. netdom computername CurrentComputerName /makeprimary:NewComputerName

  4. Restart the computer.
  5. From the command prompt, type:

    6. netdom computername NewComputerName /remove:OldComputerName

    Value | Description
CurrentComputerName | The current, or primary, computer name or IP address of the computer you are renaming.
NewComputerName | The new name for the computer. The NewComputerName must be a fully qualified domain name (FQDN). The primary DNS suffix specified in the FQDN for NewComputerName must be the same as the primary DNS suffix of CurrentComputerName or it must be contained in the list of allowed DNS suffixes specified in the msDS-AllowedDNSSuffixes attribute of the domainDns object.
OldComputerName | The old name of renamed computer.

Important

  • To rename a domain controller using the Netdom tool, the domain functional level must be set to Windows Server 2003. For more information, Related Topics.
  • Renaming a domain controller requires that you first provide a FQDN as a new computer name for the domain controller. All of the computer accounts for the domain controller must contain the updated SPN attribute and all the authoritative DNS servers for the domain name must contain the host (A) resource record for the new computer name. Both the old and new computer names are maintained until you remove the old computer name. This ensures that there will be no interruption in the ability of clients to locate or authenticate to the renamed domain controller, except when the domain controller is restarted.

Notes

  • XOX
  • XOX
  • This command-line method requires the Netdom Windows support tool. For information about installing Windows support tools, see Related Topics.
  • If the domain controller belongs to a group with a Group Policy enabled on its primary DNS suffix, the string specified in the Group Policy is used as the primary DNS suffix. The local setting is used only if the Group Policy is disabled or unspecified.
  • By default, the primary DNS suffix portion of a computer's FQDN is the same as the name of the Active Directory domain to which the computer is joined. To allow different primary DNS suffixes, a domain administrator can create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is managed by the domain administrator using Active Directory Service Interfaces (ADSI) or Lightweight Directory Access Protocol (LDAP). For more information about programming interfaces and directory access protocol, see Related Topics.
  • Domain controller locator (Locator) DNS resource records are registered by the domain controller after the renamed domain controller has been restarted. The records that are registered are available on the domain controller in the systemroot\System32\Config\Netlogon.dns file.
  • To enumerate the names with which the computer is currently configured, at a command prompt, type:

    netdom computername ComputerName /enumerate:{AlternateNames | PrimaryName | AllNames}

  • You can also specify a parameter that will use administrator credentials required to modify the computer account in Active Directory. If this parameter is not specified, Netdom uses the credentials of the user currently logged on. For more information, see the Netdom command-line help.
  • If you rename a domain controller through the System Properties dialog box instead of using the Netdom tool, DNS and Active Directory replication latency may delay the ability of clients to locate or authenticate to the renamed domain controller. The length of this latency depends on your network design and the replication topology of your organization.

Related Topics


Disable signed or encrypted LDAP traffic

Microsoft Windows Graphic

To disable signed or encrypted LDAP traffic

  1. Open Registry Editor.

    Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.
  2. In Registry Editor, navigate to the following registry key:

      Where?

      • HKEY_LOCAL_MACHINE
      • SOFTWARE
      • Microsoft
      • Windows
      • CurrentVersion
      • AdminDebug
  3. Click Edit, point to New, and then click DWORD Value.
  4. In the text box that appears, type ADsOpenObjectFlags, and then press ENTER.
  5. Double-click the ADsOpenObjectFlags registry key you just created, and then change the Value Data to one of the following values below:
    Value data (Hexadecimal) | Disables
    1 | Signing
    2 | Encryption
    3 | Encryption and Signing

Caution

  • This procedure will disable the use of signed or encrypted LDAP traffic for some Active Directory administrative tools. It is recommended that you avoid disabling this feature. For more information, see Related Topics.

Notes

  • XOX
  • To open Registry Editor, click Start, click Run, type regedit, and then click OK.

Related Topics


Manage operations master roles

  • Identify operations master roles
  • Transfer operations master roles
  • Seize operations master roles


Identify operations master roles

  • Identify the RID master
  • Identify the PDC emulator
  • Identify the infrastructure master
  • Identify the domain naming master
  • Identify the schema master


Identify the RID master

Microsoft Windows Graphic

To identify the RID master

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. Right-click the domain node, and then click Operations Masters.
  3. On the RID tab, under Operations masters, view the current RID master.

Notes

  • XOX
  • XOX
  • Every domain has only one RID master. To identify the RID master in a different domain, target the appropriate domain before clicking Operations Masters.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery server -hasfsmo rid

Value | Description
-hasfsmo | Finds the domain controller (server object) that currently holds the requested operations masters role.
rid | Requests the RID master of the current domain.

Notes

  • XOX
  • XOX

Related Topics


Identify the PDC emulator

Microsoft Windows Graphic

To identify the PDC emulator

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. Right-click the domain node, and then click Operations Masters.
  3. On the PDC tab, under Operations masters, view the operations masters that will serve as the PDC emulator.

Notes

  • XOX
  • XOX
  • Every domain has only one PDC emulator master. To identify the PDC emulator in a different domain, target the appropriate domain before clicking Operations Masters.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery server -hasfsmo pdc

Value | Description
-hasfsmo | Finds the domain controller (server object) that currently holds the requested operations masters role.
pdc | Requests the PDC emulator master of the current domain.

Note

  • XOX
  • XOX

Related Topics


Identify the infrastructure master

Microsoft Windows Graphic

To identify the infrastructure master

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. Right-click the domain node, and then click Operations Masters.
  3. On the Infrastructure tab, under Operations masters, view the name of the current infrastructure master.

Notes

  • XOX
  • XOX
  • Every domain has only one infrastructure master. To identify the infrastructure master in a different domain, target the appropriate domain before clicking Operations Masters.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery server -hasfsmo infr

Value | Description
-hasfsmo | Finds the domain controller (server object) that currently holds the requested operations masters role.
infr | Requests the infrastructure master of the forest.

Notes

  • XOX
  • XOX

Related Topics


Identify the domain naming master

Microsoft Windows Graphic

To identify the domain naming master

Using the Windows interface

  1. Open Active Directory Domains and Trusts.
  2. Right-click Active Directory Domains and Trusts, and then click Operations Master.
  3. Under Domain naming operations master, view the current domain naming operations master.

Notes

  • XOX
  • XOX
  • Every forest has only one domain naming master. To identify the domain naming master in a different forest, target the appropriate forest before clicking Operations Master.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery server -hasfsmo name

Value | Description
-hasfsmo | Finds the domain controller (server object) that currently holds the requested operations master role.
name | Requests the domain naming master of the forest.

Notes

  • XOX
  • XOX

Related Topics


Identify the schema master

Microsoft Windows Graphic

To identify the schema master

Using the Windows interface

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, right-click Active Directory Schema, and then click Operations Master.
  3. Under Current Schema Master, view the current schema operations master.

Notes

  • XOX
  • XOX
  • Each forest has only one schema master. To identify the schema master in a different forest, target the appropriate forest before clicking Operations Master.
  • If the Active Directory Schema snap-in is not installed, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery server -hasfsmo schema

Value | Description
-hasfsmo | Finds the domain controller (server object) that currently holds the requested operations master role.
schema | Requests the schema master of the forest.

Notes

  • XOX
  • XOX

Related Topics


Transfer operations master roles

  • Transfer the RID master role
  • Transfer the PDC emulator role
  • Transfer the infrastructure master role
  • Transfer the domain naming master role
  • Transfer the schema master role


Transfer the RID master role

Microsoft Windows Graphic

To transfer the RID master role

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Active Directory Users and Computers, and then click Connect to Domain Controller.

  3. In Enter the name of another domain controller, type the name of the domain controller you want to hold the RID master role.

    Or, click the domain controller in the list of available domain controllers.

  4. In the console tree, right-click Active Directory Users and Computers, point to All Tasks, and then click Operations Masters.
  5. Click the RID tab, and then click Change.

Notes

  • XOX
  • XOX
  • To transfer a role to another domain controller, you may first need to change the focus of Active Directory Users and Computers to the target domain controller. To do this, right-click Active Directory Users and Computers, click Connect to Domain Controller, and then click the target domain controller.

Using a command line

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. roles

  4. At the fsmo maintenance command prompt, type:

    5. connection

  5. At the server connections command prompt, type:

    6. connect to server DomainController

  6. At the server connections command prompt, type:

    7. quit

  7. At the fsmo maintenance command prompt, type:

    8. transfer RID master

Value | Description
DomainController | The domain controller to which you want to assign the new operations master role.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at the ntdsutil command prompt, type:

    roles ENTER

    ? ENTER

Related Topics


Transfer the PDC emulator role

Microsoft Windows Graphic

To transfer the PDC emulator role

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Active Directory Users and Computers, and then click Connect to Domain Controller.

  3. In Enter the name of another domain controller, type the name of the domain controller you want to hold the PDC emulator role.

    Or, click the domain controller in the list of available domain controllers.

  4. In the console tree, right-click Active Directory Users and Computers, point to All Tasks, and then click Operations Masters.
  5. Click the PDC tab, and then click Change.

Notes

  • XOX
  • XOX
  • To transfer a role to another domain controller, you may first need to change the focus of Active Directory Users and Computers to the target domain controller. To do this, right-click Active Directory Users and Computers, click Connect to Domain Controller, and then click the target domain controller.

Using a command line

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. roles

  4. At the fsmo maintenance command prompt, type:

    5. connection

  5. At the server connections command prompt, type:

    6. connect to server DomainController

  6. At the server connections command prompt, type:

    7. quit

  7. At the fsmo maintenance command prompt, type:

    8. transfer PDC

Value | Description
DomainController | The domain controller to which you want to assign the new operations master role.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at the ntdsutil command prompt, type:

    roles ENTER

    ? ENTER

Related Topics


Transfer the infrastructure master role

Microsoft Windows Graphic

To transfer the infrastructure master role

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Active Directory Users and Computers, and then click Connect to Domain Controller.

  3. In Enter the name of another domain controller, type the name of the domain controller you want to hold the infrastructure master role.

    Or, click the domain controller in the list of available domain controllers.

  4. In the console tree, right-click Active Directory Users and Computers, point to All Tasks, and then click Operations Masters.
  5. On the Infrastructure tab, click Change.

Notes

  • XOX
  • XOX
  • To transfer a role to another domain controller, you may first need to change the focus of Active Directory Users and Computers to the target domain controller. To do this, right-click Active Directory Users and Computers, click Connect to Domain Controller, and then click the target domain controller.

Using a command line

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. roles

  4. At the fsmo maintenance command prompt, type:

    5. connection

  5. At the server connections command prompt, type:

    6. connect to server DomainController

  6. At the server connections command prompt, type:

    7. quit

  7. At the fsmo maintenance command prompt, type:

    8. transfer infrastructure master

Value | Description
DomainController | The domain controller to which you want to assign the new operations master role.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at the ntdsutil command prompt, type:

    roles ENTER

    ? ENTER

Related Topics


Transfer the domain naming master role

Microsoft Windows Graphic

To transfer the domain naming master role

Using the Windows interface

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click Active Directory Domains and Trusts, and then click Connect to Domain Controller.

  3. In Enter the name of another domain controller, type the name of the domain controller you want to hold the domain naming master role.

    Or, click the domain controller in the list of available domain controllers.

  4. In the console tree, right-click Active Directory Domains and Trusts, and then click Operations Master.
  5. Click Change.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • To transfer a role to another domain controller, you may first need to change the focus of Active Directory Domains and Trusts to the target domain controller. To do this, right-click Active Directory Domains and Trusts, click Connect to Domain Controller, and then click the target domain controller.
  • Unlike a domain naming master in a forest set to the Windows 2000 functional level, a domain naming master in a forest set to the Windows Server 2003 functional level is not required to be enabled as a global catalog.

Using a command line

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. roles

  4. At the fsmo maintenance command prompt, type:

    5. connection

  5. At the server connection command prompt, type:

    6. connect to server DomainController

  6. At the server connection command prompt, type:

    7. quit

  7. At the fsmo maintenance command prompt, type:

    8. transfer domain naming master

Value | Description
DomainController | The domain controller to which you want to assign the new operations master role.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • To view the complete syntax for this command, at the ntdsutil command prompt, type:

    roles ENTER

    ? ENTER

  • Unlike a domain naming master in a forest set to the Windows 2000 functional level, a domain naming master in a forest set to the Windows Server 2003 functional level is not required to be enabled as a global catalog.

Related Topics


Transfer the schema master role

Microsoft Windows Graphic

To transfer the schema master role

Using the Windows interface

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, right-click Active Directory Schema and then click Change Domain Controller.
  3. Click Specify Name and type the name of the domain controller that you want to hold the schema master role.
  4. In the console tree, right-click Active Directory Schema, and then click Operations Master.
  5. Click Change.

Notes

  • XOX
  • The Active Directory Schema snap-in must be connected to the schema master to perform this procedure. The Active Directory Schema snap-in connects to the schema master by default when it is started.
  • If the Active Directory Schema snap-in is not installed, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. roles

  4. At the fsmo maintenance command prompt, type:

    5. connection

  5. At the server connections command prompt, type:

    6. connect to server DomainController

  6. At the server connections command prompt, type:

    7. quit

  7. At the fsmo maintenance command prompt, type:

    8. transfer schema master

Value | Description
DomainController | The domain controller to which you want to transfer the role.

Notes

  • XOX
  • XOX
  • XOX
  • To view the complete syntax for this command, at the ntdsutil command prompt, type:

    roles ENTER

    ? ENTER

Related Topics


Seize operations master roles

  • Seize the RID master role
  • Seize the PDC emulator role
  • Seize the infrastructure master role
  • Seize the domain naming master role
  • Seize the schema master role


Seize the RID master role

Microsoft Windows graphic

To seize the RID master role

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. roles

  4. At the fsmo maintenance command prompt, type:

    5. connections

  5. At the server connections command prompt, type:

    6. connect to server DomainController

  6. At the server connections prompt, type:

    7. quit

  7. At the fsmo maintenance command prompt, type:

    8. seize RID master

Value | Description
DomainController | The domain controller to which you want to assign the new operations master role. Use only for recovery purposes.

Caution

  • Do not seize the RID master role if you can transfer it instead. Seizing the RID master is a drastic step that should be considered only if the current operations master will never be available again. For more information about transferring operations master roles, see Related Topics.

Notes

  • XOX
  • XOX
  • Before seizing the RID master, use the repadmin command-line tool to verify whether the new operations master has received any updates performed by the previous role holder, and then remove the current operations master from the network. For more information about operations master roles and the Active Directory command-line tools, see Related Topics.

Related Topics


Seize the PDC emulator role

Microsoft Windows graphic

To seize the PDC emulator role

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. roles

  4. At the fsmo maintenance command prompt, type:

    5. connections

  5. At the server connections command prompt, type:

    6. connect to server DomainController

  6. At the server connections prompt, type:

    7. quit

  7. At the fsmo maintenance command prompt, type:

    8. seize PDC

Value | Description
DomainController | The domain controller to which you want to assign the new operations master role. Use only for recovery purposes.

Caution

  • Do not seize the PDC emulator role if you can transfer it instead. Seizing the PDC emulator is a drastic step that should be considered only if the current operations master will never be available again. For more information about transferring operations master roles, see Related Topics.

Notes

  • XOX
  • XOX
  • Before seizing the PDC emulator role, use the repadmin command-line tool to verify whether the new operations master has received any updates performed by the previous role holder, and then remove the current operations master from the network. For more information about operations master roles and the Active Directory command-line tools, see Related Topics.

Related Topics


Seize the infrastructure master role

Microsoft Windows graphic

To seize the infrastructure master role

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. roles

  4. At the fsmo maintenance command prompt, type:

    5. connections

  5. At the server connections command prompt, type:

    6. connect to server DomainController

  6. At the server connections prompt, type:

    7. quit

  7. At the fsmo maintenance command prompt, type:

    8. seize infrastructure master

Value | Description
DomainController | The domain controller to which you want to assign the new operations master role. Use only for recovery purposes.

Caution

  • Do not seize the infrastructure master role if you can transfer it instead. Seizing the infrastructure master role is a drastic step that should be considered only if the current operations master will never be available again. For more information about transferring operations master roles, see Related Topics.

Notes

  • XOX
  • XOX
  • Before seizing the infrastructure master role, use the repadmin command-line tool to verify whether the new operations master has received any updates performed by the previous role holder, and then remove the current operations master from the network. For more information about operations master roles and the Active Directory command-line tools, see Related Topics.

Related Topics


Seize the domain naming master role

Microsoft Windows graphic

To seize the domain naming master role

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. roles

  4. At the fsmo maintenance command prompt, type:

    5. connections

  5. At the server connections command prompt, type:

    6. connect to server DomainController

  6. At the server connections prompt, type:

    7. quit

  7. At the fsmo maintenance command prompt, type:

    8. seize domain naming master

Value | Description
DomainController | The domain controller to which you want to assign the new operations master role. Use only for recovery purposes.

Caution

  • Do not seize the domain naming master role if you can transfer it instead. Seizing the domain naming master role is a drastic step that should be considered only if the current operations master will never be available again. For more information about transferring operations master roles, see Related Topics.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Before seizing the domain naming master role, use the repadmin command-line tool to verify whether the new operations master has received any updates performed by the previous role holder, and then remove the current operations master from the network. For more information about operations master roles and the Active Directory command-line tools, see Related Topics.

Related Topics


Seize the schema master role

Microsoft Windows graphic

To seize the schema master role

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. roles

  4. At the fsmo maintenance command prompt, type:

    5. connections

  5. At the server connections command prompt, type:

    6. connect to server DomainController

  6. At the server connections prompt, type:

    7. quit

  7. At the fsmo maintenance command prompt, type:

    8. seize schema master

Value | Description
DomainController | The domain controller to which you want to assign the new operations master role. Use only for recovery purposes.

Caution

  • Do not seize the schema master role if you can transfer it instead. Seizing the schema master role is a drastic step that should be considered only if the current operations master will never be available again. For more information about transferring operations master roles, see Related Topics.

Notes

  • XOX
  • XOX
  • Before seizing the schema master role, use the repadmin command-line tool to verify whether the new operations master has received any updates performed by the previous role holder, and then remove the current operations master from the network. For more information about operations master roles and the Active Directory command-line tools, see Related Topics.

Related Topics


Manage trusts

  • Verify a trust
  • Remove a trust
  • Create a shortcut trust
  • Create an external trust
  • Create a realm trust
  • Select the scope of authentication for users
  • Manage forest trusts


Verify a trust

Microsoft Windows Graphic

To verify a trust

Using the Windows interface

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain that contains the trust you want to verify, and then click Properties.
  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the trust to be verified, and then click Properties.
  4. Click Validate.
  5. Do one of the following, and then click OK:
    • Click No, do not validate the incoming trust.

      If you choose this option, it is recommended that you repeat this procedure for the reciprocal domain.

    • Click Yes, validate the incoming trust.

      If you choose this option, you must type a user account and password with administrative credentials for the reciprocal domain.

Notes

  • XOX
  • XOX
  • You can verify trusts for shortcut, external, and forest trusts but not realm trusts.

Using a command line

  1. Open Command Prompt.
  2. Type:

    netdom trust TrustingDomainName /d:TrustedDomainName /verify

Value | Description
TrustingDomainName | Specifies the DNS name of the trusting domain in the trust that is being verified.
TrustedDomainName | Specifies the DNS name of the domain that is trusted in the trust that is being verified.

Notes

  • XOX
  • XOX
  • You can verify trusts for shortcut, external, and forest trusts but not realm trusts.
  • This command-line method requires the Netdom Windows support tool. For information about installing Windows support tools, see Related Topics.
  • To view the complete syntax for this command, at a command prompt, type:

    netdom trust | more

Related Topics


Remove a trust

Microsoft Windows Graphic

To remove a trust

Using the Windows interface

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain that contains the trust you want to remove, and then click Properties.
  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the trust to be removed, and then click Remove.
  4. Do one of the following, and then click OK:
    • Click No, remove the trust from the local domain only.

      If you choose this option, it is recommended that you repeat this procedure for the reciprocal domain.

    • Click Yes, remove the trust from both the local domain and the other domain.

      If you choose this option, you must type a user account and password with administrative credentials for the reciprocal domain.

Notes

  • XOX
  • XOX
  • It is not possible to revoke the default two-way, transitive trusts between domains in a forest. Explicitly created shortcut trusts can be deleted.

Using a command line

  1. Open Command Prompt.
  2. Type:

    netdom trust TrustingDomainName /d:TrustedDomainName /remove /UserD:User /PasswordD:*

Value | Description
TrustingDomainName | Specifies the DNS name of the trusting domain in the trust that is being removed.
TrustedDomainName | Specifies the DNS name of the domain that is trusted in the trust that is being removed.

Notes

  • XOX
  • XOX
  • This command-line method requires the Netdom Windows support tool. For information about installing Windows support tools, see Related Topics.
  • To view the complete syntax for this command, at a command prompt, type:

    netdom trust | more

Related Topics


Create a shortcut trust

Microsoft Windows Graphic

To create a shortcut trust

Using the Windows interface

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain node for the domain you want to establish a shortcut trust with, and then click Properties.
  3. On the Trusts tab, click New Trust, and then click Next.
  4. On the Trust Name page, type the DNS name (or NetBIOS name) of the domain, and then click Next.
  5. On the Direction of Trust page, do one of the following:
    • To create a two-way, shortcut trust, click Two-way.

      Users in this domain and users in the specified domain can can use this trust path.

    • To create a one-way, incoming shortcut trust, click One-way:incoming.

      Users in the specified domain will not be able to use this trust path.

    • To create a one-way, outgoing shortcut trust, click One-way:outgoing.

      Users in this domain will not be able to use this trust path.

  6. Continue to follow the wizard.

Notes

  • XOX
  • XOX
  • If you have the appropriate administrative credentials for each domain, you can create both sides of a shortcut trust at the same time by clicking Both this domain and the specified domain on the Sides of Trust page. For more information, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    netdom trust TrustingDomainName /d:TrustedDomainName /add

Value | Description
TrustingDomainName | Specifies the DNS name (or NetBIOS name) of the trusting domain in the trust being created.
TrustedDomainName | Specifies the DNS name (or NetBIOS name) of the domain that will be trusted in the trust being created.

Notes

  • XOX
  • XOX
  • This command-line method requires the Netdom Windows support tool. For information about installing Windows support tools, see Related Topics.
  • Other switches can be used to assign a password or determine the direction of the trust. For example, to make the above trust a two-way, transitive trust you would use the following syntax:

    • netdom trust TrustingDomainName /d:TrustedDomainName /add /twoway

  • To view the complete syntax for this command, at a command prompt, type:

    netdom trust | more

Related Topics


Create an external trust

Microsoft Windows Graphic

To create an external trust

Using the Windows interface

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain node for the domain you want to establish a trust with, and then click Properties.
  3. On the Trusts tab, click New Trust, and then click Next.
  4. On the Trust Name page, type the DNS name (or NetBIOS name) of the domain, and then click Next.
  5. On the Trust Type page, click External trust, and then click Next.
  6. On the Direction of Trust page, do one of the following:
    • To create a two-way, external trust, click Two-way.

      Users in this domain and users in the specified domain can access resources in either domain.

    • To create a one-way, incoming external trust, click One-way:incoming.

      Users in the specified domain will not be able to access any resources in this domain.

    • To create a one-way, outgoing external trust, click One-way:outgoing.

      Users in this domain will not be able to access any resources in the specified domain.

  7. Continue to follow the wizard.

Notes

  • XOX
  • XOX
  • If you have the appropriate administrative credentials for each domain, you can create both sides of an external trust at the same time by clicking Both this domain and the specified domain on the Sides of Trust page. For more information, see Related Topics.
  • If you want to allow users from the specified domain to obtain access to all the resources in this domain, click Allow authentication for all resources in the local domain on the Outgoing Trust Properties page. This option should be used when both domains belong to the same organization.
  • If you want to restrict users in the specified domain from obtaining access to any of the resources in this domain, click Allow authentication only for selected resources in the local domain on the Outgoing Trust Properties page. This option should be used when each domain belongs to a separate organization.

Using a command line

  1. Open Command Prompt.
  2. Type:

    netdom trust TrustingDomainName /d:TrustedDomainName /add

Value | Description
TrustingDomainName | Specifies the DNS name (or NetBIOS name) of the trusting domain in the trust being created.
TrustedDomainName | Specifies the DNS name (or NetBIOS name) of the domain that will be trusted in the trust being created.

Notes

  • XOX
  • XOX
  • This command-line method requires the Netdom Windows support tool. For information about installing Windows support tools, see Related Topics.
  • Other switches can be used to assign a password or determine the direction of the trust. For example, to make a two-way, transitive trust, you can use the following syntax:

    • netdom trust TrustingDomainName /d:TrustedDomainName /add /twoway

  • To view the complete syntax for this command, at a command prompt, type:

    netdom trust | more

Related Topics


Create a realm trust

Microsoft Windows Graphic

To create a realm trust

Using the Windows interface

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain node for the domain you want to administer, and then click Properties.
  3. On the Trusts tab, click New Trust, and then click Next.
  4. On the Trust Name page, type the realm name for the target realm, and then click Next.
  5. On the Trust Type page, select the Realm trust option, and then click Next.
  6. On the Transitivity of Trust page, do one of the following:
    • To form a trust relationship with the domain and the specified realm, click Nontransitive, and then click Next.
    • To form a trust relationship with the domain and the specified realm and all trusted realms, click Transitive, and then click Next.
  7. On the Direction of Trust page, do one of the following:
    • To create a two-way, realm trust, click Two-way.

      Users in this domain and users in the specified realm can access resources in either domain or realm.

    • To create a one-way, incoming realm trust, click One-way:incoming.

      Users in the specified realm will not be able to access any resources in this domain.

    • To create a one-way, outgoing realm trust, click One-way:outgoing.

      Users in this domain will not be able to access any resources in the specified realm.

  8. Continue to follow the wizard.

Notes

  • XOX
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    netdom trust TrustingDomainName /d:TrustedDomainName /add /realm /PasswordT:NewRealmTrustPassword

Value | Description
TrustingDomainName | Specifies the DNS name of the trusting domain in the new realm trust.
TrustedDomainName | Specifies the DNS name of the domain that will be trusted in the new realm trust.
NewRealmTrustPassword | Specifies the trust password for the new realm trust. This password must match the one used in the Kerberos realm.

Notes

  • XOX
  • XOX
  • This command-line method requires the Netdom Windows support tool. For information about installing Windows support tools, see Related Topics.
  • Other switches can be used to assign a password or determine the direction of the trust. For example, to make the above trust a two-way, transitive trust you would use the following syntax:

    • netdom trust TrustingDomainName /d:TrustedDomainName /add /realm /twoway

  • To view the complete syntax for this command, at a command prompt, type:

    netdom trust | more

Related Topics


Select the scope of authentication for users

Microsoft Windows Graphic

To select the scope of authentication for users

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain node for the domain you want to administer, and then click Properties.
  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), do one of the following:
    • To select the scope of authentication for users authenticating through an external trust, click the external trust that you want to administer, and then click Properties. On the Authentication tab, click either Domain-wide authentication or Selective authentication.
    • To select the scope of authentication for users authenticating through a forest trust, click the forest trust that you want to administer, and then click Properties. On the Authentication tab, click either Forest-wide authentication or Selective authentication.

Notes

  • To perform this procedure for an external trust, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • To perform this procedure for a forest trust, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority.
  • XOX
  • For an external trust, if you select Selective authentication, you need to manually enable permissions on the local domain and on the resource to which you want users in the external domain to have access.
  • For a forest trust, if you select Selective authentication, you need to manually enable permissions on each domain and resource in the local forest to which you want users in the second forest to have access.
  • You can use selective authentication only on external and forest trusts. For more information about selective authentication, see Related Topics.

Related Topics


Manage forest trusts

  • Create a forest trust
  • Change the routing status of a name suffix
  • Enable or disable an existing name suffix from routing
  • Exclude name suffixes from routing to a local forest


Create a forest trust

Microsoft Windows graphic

To create a forest trust

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain node for the forest root domain, and then click Properties.
  3. On the Trust tab, click New Trust, and then click Next.
  4. On the Trust Name page, type the DNS name (or NetBIOS name) of another forest, and then click Next.
  5. On the Trust Type page, click Forest trust, and then click Next.
  6. On the Direction of Trust page, do one of the following:
    • To create a two-way, forest trust, click Two-way.

      Users in this forest and users in the specified forest can access resources in either forest.

    • To create a one-way, incoming forest trust, click One-way:incoming.

      Users in the specified forest will not be able to access any resources in this forest.

    • To create a one-way, outgoing forest trust, click One-way:outgoing.

      Users in this forest will not be able to access any resources in the specified forest.

  7. Continue to follow the wizard.

Important

  • To successfully create a forest trust, your environment will need to be set up properly. For more information, see the checklist for creating a forest trust in Related Topics.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • If you are a member of the Incoming Forest Trust Builders group, you can create one-way, incoming forest trusts to this forest.
  • XOX
  • On a domain controller running Windows Server 2003, the forest root domain is the first domain listed in the console tree in Active Directory Domains and Trusts. This configuration is not provided on domain controllers running Windows 2000.
  • If you have the appropriate administrative credentials for each forest, you can create both sides of a forest trust at the same time by clicking Both this domain and the specified domain on the Sides of Trust page. For more information, see Related Topics.
  • If you want users from the specified forest to have access to all computers in the local forest, on the Outgoing Trust Properties page, click Forest-wide authentication. This option is preferred when both forests belong to the same organization.
  • If you want to selectively limit authentication to particular users and groups from the specified forest, on the Outgoing Trust Properties page, click Selective authentication. This option is preferred if the specified forest belongs to a separate organization.
  • In addition to creating new trusts, you can modify existing trusts by clicking the Trust tab.

Related Topics


Change the routing status of a name suffix

Microsoft Windows graphic

To change the routing status of a name suffix

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain node for the domain you want to administer, and then click Properties.
  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the forest trust that you want to administer, and then click Properties.
  4. On the Name Suffix Routing tab, under Name suffixes in the x.x forest, click the suffix for which you want to modify the routing status, and then click Edit.
  5. In Existing name suffixes in x.x, click the suffix that you want to modify, and then click Enable or Disable.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • You cannot enable a name suffix that is in conflict. If the conflict is with a local UPN name suffix, then you need to remove the local UPN name suffix before you can enable the routing name. If the conflict is with a name claimed by another trust partner, then you will need to disable the name in the other trust before it can be enabled for this trust.
  • To view a log of name suffixes, DNS names, NetBIOS names and the status associated with this trust, click Save As. This log can assist you in troubleshooting authentication problems.
  • For information about trusts, see Related Topics.

Related Topics


Enable or disable an existing name suffix from routing

Microsoft Windows graphic

To enable or disable an existing name suffix from routing

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain node for the domain you want to administer, and then click Properties.
  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the forest trust that you want to administer, and then click Properties.
  4. Click the Name Suffix Routing tab, under Name suffixes in the x.x forest, do one of the following:
    • To enable a name suffix, click the suffix that you want to enable, and then click Enable. If the Enable button appears dimmed, then the name suffix is already enabled.
    • To disable a name suffix, click the suffix that you want to disable, and then click Disable. If the Disable button appears dimmed, then the name suffix is already disabled.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • When you disable a name suffix, all children of that DNS name will also be disabled.
  • You cannot enable a name suffix that is in conflict. If the conflict is with a local UPN name suffix, then you need to remove the local UPN name suffix before you can enable the routing name. If the conflict is with a name claimed by another trust partner, then you will need to disable the name in the other trust before it can be enabled for this trust.
  • For information about trusts, see Related Topics.

Related Topics


Exclude name suffixes from routing to a local forest

Microsoft Windows graphic

To exclude name suffixes from routing to a local forest

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the domain node for the domain you want to administer, and then click Properties.
  3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click the forest trust that you want to administer, and then click Properties.
  4. On the Name Suffix Routing tab, under Name suffixes in the x.x forest, click the unique name suffix for which you want to exclude the routing status, and then click Edit.
  5. In Name suffixes to exclude from routing to x.x, click Add, type a Domain Name System (DNS) name suffix that is subordinate to the unique name suffix, and then click OK.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • When you exclude a name suffix, all children of that DNS name will also be excluded.
  • To view a log of name suffixes, DNS names, NetBIOS names and the status associated with this trust, click Save As. This log can assist you in troubleshooting authentication problems.
  • For information about trusts, see Related Topics.

Related Topics


Manage forests

  • Raise the forest functional level
  • Manage application directory partitions
  • Manage the schema


Raise the forest functional level

Microsoft Windows graphic

To raise the forest functional level

  1. Open Active Directory Domains and Trusts.
  2. In the console tree, right-click the Active Directory Domains and Trusts node, and then click Raise Forest Functional Level.
  3. In Select an available forest functional level, click Windows Server 2003, and then click Raise.

Caution

  • If you have or will have any domain controllers running Windows NT 4.0 and earlier or Windows 2000, then do not raise the forest functional level to Windows Server 2003. Once the forest functional level has been set to Windows Server 2003, it cannot be changed back to Windows 2000.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Windows 2000 native is the minimum domain functionality requirement for raising the forest functional level to Windows Server 2003.
  • To raise the forest functional level, you must first upgrade (or demote) all existing Windows 2000 domain controllers within your forest.
  • If you are unable to raise the forest functional level, you can click Save As in the Raise Forest Functional Level dialog box to save a log file that specifies which domain controllers in the forest still need to be upgraded from Windows NT or Windows 2000.
  • The current forest functional level is displayed under Current forest functional level in the Raise Forest Functional Level dialog box.

Related Topics


Manage application directory partitions

  • Create or delete an application directory partition
  • Add or remove an application directory partition replica
  • Display application directory partition information
  • Set an application directory partition reference domain
  • Prepare a cross-reference object
  • Set a notification delay


Create or delete an application directory partition

Microsoft Windows graphic

To create or delete an application directory partition

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. domain management

  4. At the domain management command prompt, type:

    5. connection

  5. At the connection command prompt, type:

    6. connect to server ServerName

  6. At the connection command prompt, type:

    7. quit

  7. At the domain management command prompt, do one of the following:
    • To create an application directory partition, type:

      • create nc ApplicationDirectoryPartition DomainController

    • To delete an application directory partition, type:

      • delete nc ApplicationDirectoryPartition

Value | Description
ServerName | The DNS name of the domain controller to which you want to connect.
ApplicationDirectoryPartition | The distinguished name of the application directory partition that you want to create or delete. For example, the distinguished name of the application directory partition test.microsoft.com is dc=test, dc=Microsoft, dc=com.
DomainController | The DNS name of the domain controller on which to create or delete the application directory partition. Type NULL to create the application directory partition on the domain controller to which you are currently connected.

Caution

  • Removing the last replica of an application directory partition will result in the permanent loss of any data contained in the partition. For more information, see Related Topics.

Notes

  • XOX
  • XOX

Related Topics


Add or remove an application directory partition replica

Microsoft Windows graphic

To add or remove an application directory partition replica

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. domain management

  4. At the domain management command prompt, type:

    5. connection

  5. At the connection command prompt, type:

    6. connect to server DomainController

  6. At the connection command prompt, type:

    7. quit

  7. At the domain management command prompt, do one of the following:
    • To add an application directory partition replica, type:

      • add nc replica ApplicationDirectoryPartition DomainController

    • To remove an application directory partition replica, type:

      • remove nc replica ApplicationDirectoryPartition DomainController

Value | Description
DomainController | The DNS name of the domain controller on which to add or remove the replica of the application directory partition.
ApplicationDirectoryPartition | The distinguished name for the application directory partition of which you want to add or remove a replica. For example, the distinguished name of the application directory partition test.microsoft.com is dc=test, dc=microsoft, dc=com.

Caution

  • Removing the last replica of an application directory partition will result in the permanent loss of any data contained in the partition.

Notes

  • XOX
  • XOX
  • The value NULL can be used for the DomainController parameter of the add nc replica and remove nc replica commands if you are adding or removing the application directory partition replica on the domain controller to which you are currently connected.

Related Topics


Display application directory partition information

Microsoft Windows graphic

To display application directory partition information

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command prompt, type:

    4. domain management

  4. At the domain management command prompt, type:

    5. connection

  5. At the connection command prompt, type:

    6. connect to server DomainController

  6. At the connection command prompt, type:

    7. quit

  7. At the domain management command prompt, do one or more of the following:
    • To show the distinguished names of known directory partitions, type:

      list

    • To show the reference domain and replication delays for an application directory partition, type:

      list nc information DistinguishedName

    • To show the list of domain controllers in the replica set for an application directory partition, type:

      list nc replicas DistinguishedName

Value | Description
DomainController | The DNS name of the domain controller for which you want to display application directory partition information.
DistinguishedName | The distinguished name of the application directory partition you want information about.

Notes

  • XOX
  • XOX

Related Topics


Set an application directory partition reference domain

Microsoft Windows graphic

To set an application directory partition reference domain

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command, type:

    4. domain management

  4. At the domain management command, type:

    5. connection

  5. At the connection command, type:

    6. connect to server DomainController

  6. At the connection command, type:

    7. quit

  7. At the domain management command, type:

    8. set nc reference domain ApplicationDirectoryPartition ReferenceDomain

Value | Description
DomainController | The DNS name of the domain controller on which the application directory partition resides.
ApplicationDirectoryPartition | The distinguished name of the application directory partition for which you want to set the reference domain. For example, the distinguished name of the application directory partition test.microsoft.com is dc=test, dc=microsoft, dc=com.
ReferenceDomain | The distinguished name of the domain that you want to be the reference domain for this application directory partition.

Notes

  • XOX
  • XOX

Related Topics


Prepare a cross-reference object

Microsoft Windows graphic

To prepare a cross-reference object

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command, type:

    4. domain management

  4. At the domain management command, type:

    5. connection

  5. At the connection command, type:

    6. connect to server DomainController

  6. At the connection command, type:

    7. quit

  7. At the domain management command, type:

    8. precreate ObjectName DomainController

Value | Description
DomainController | The DNS name of the domain controller on which the object will reside.
ObjectName | The distinguished name of the object that you want to create.

Notes

  • XOX
  • XOX
  • This procedure can be used for either preparing a domain for use with the Active Directory Installation Wizard or preparing an application directory partition.

Related Topics


Set a notification delay

Microsoft Windows graphic

To set a notification delay

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command, type:

    4. domain management

  4. At the domain management command, type:

    5. connection

  5. At the connection command, type:

    6. connect to server DomainController

  6. At the connection command, type:

    7. quit

  7. At the domain management command, type:

    8. set nc replicate notification delay DirectoryPartition DelayInSeconds AdditionalDelayInSeconds

Value | Description
DirectoryPartition | The distinguished name of the directory partition for which you want to set notification delays.
DelayInSeconds | The number of seconds to delay before sending the change notification to the first replication partner.
AdditionalDelayInSeconds | The number of seconds to delay before sending subsequent change notifications to the remaining replication partners.

Notes

  • XOX
  • XOX
  • This procedure can be applied to any directory partition including application directory partitions.

Related Topics


Manage the schema

  • Install the Active Directory Schema snap-in
  • Add a member to the Schema Admins group
  • Remove a member from the Schema Admins group
  • Modify schema permissions
  • Add an attribute to the global catalog
  • Index an attribute in Active Directory
  • Index an attribute for a containerized search
  • View a schema class or attribute definition
  • Modify a schema class or attribute definition
  • Add a schema class or attribute definition
  • Deactivate a class or attribute
  • Reactivate a class or attribute
  • Reload the schema
  • Enable schema changes on a Windows 2000 domain controller


Install the Active Directory Schema snap-in

Microsoft Windows graphic

To install the Active Directory Schema snap-in

  1. Open Command Prompt.
  2. Type:

    regsvr32 schmmgmt.dll

    This command will register schmmgmt.dll on your computer. For more information about using regsvr32, see Related Topics.

  3. Click Start, click Run, type mmc /a, and then click OK.
  4. On the File menu, click Add/Remove Snap-in, and then click Add.
  5. Under Snap-in, double-click Active Directory Schema, click Close, and then click OK.
  6. To save this console, on the File menu, click Save.
  7. In Save in, point to the systemroot \system32 directory.
  8. In File name, type schmmgmt.msc, and then click Save.
  9. To create a shortcut on your Start menu:
    • Right-click Start, click Open all Users, double-click the Programs folder, and then double-click the Administrative Tools folder.
    • On the File menu, point to New, and then click Shortcut.
    • In the Create Shortcut Wizard, in Type the location of the item, type schmmgmt.msc, and then click Next.
    • On the Select a Title for the Program page, in Type a name for this shortcut, type Active Directory Schema, and then click Finish.

Caution

  • Modifying the schema is an advanced operation best performed by experienced programmers and system administrators. For detailed information about modifying the schema, see the Active Directory Programmer's Guide at the Microsoft Web site. (http://msdn.microsoft.com/)

Notes

  • To perform this procedure on a domain controller, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • You can also run the Active Directory Schema snap-in from a computer running XOX. Simply install the Windows Server 2003 Administration Tools Pack on the computer, and then complete step 9 above. For more information about the Administration Tools Pack, see Related Topics.
  • The Windows Server 2003 Administration Tools Pack cannot be installed on computers running Windows 2000 Professional or Windows 2000 Server.

Related Topics


Add a member to the Schema Admins group

Microsoft Windows graphic

To add a member to the Schema Admins group

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users in the forest root domain.

    3. Where?

    • Active Directory Users and Computers
    • forest root domain
    • Users

    Or, click the folder that contains the user account.

  3. In the details pane, right-click the user account that you want to add, and then click Properties.
  4. Click the Member Of tab, and then click Add.
  5. In Enter the object names to select, type Schema Admins, and then click OK.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • To add users and computers to a group, you can also select the users and computers to be added, click Adds the selected objects to a group you specify. on the toolbar, and then click the group into which they will be added.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmod group GroupDN -addmbr MemberDN

Value | Description
GroupDN | Specifies the distinguished name of the Schema Admins group in your root domain. For example, if the name of your root domain is example.microsoft.com, you would type: "cn=schema admins,cn=users,dc=example,dc=microsoft,dc=com"
MemberDN | Specifies the distinguished name of the user you want to add to the Schema Admins group. For example, if you want to add a user named "Mary Baker" to the Schema Admins group, you would type: "cn=mary baker,cn=users,dc=example,dc=microsoft,dc=com"

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • To view the complete syntax for this command, at a command prompt type:

    dsmod group /?

Related Topics


Remove a member from the Schema Admins group

Microsoft Windows graphic

To remove a member from the Schema Admins group

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users in the forest root domain.

    3. Where?

    • Active Directory Users and Computers
    • forest root domain
    • Users
  3. In the details pane, right-click the Schema Admins group, and then click Properties.
  4. On the Members tab, click the member you want to delete, and then click Remove.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsmod group GroupDN -rmmbr MemberDN

Value | Description
GroupDN | Specifies the distinguished name of the Schema Admins group in your root domain. For example, if the name of your root domain is example.microsoft.com, you would type: "cn=schema admins,cn=users,dc=example,dc=microsoft,dc=com"
MemberDN | Specifies the distinguished name of the user you want to remove from the Schema Admins group. For example, if you want to remove a user named "Mary Baker" from the Schema Admins group, you would type: "cn=mary baker,cn=users,dc=example,dc=microsoft,dc=com"

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • To view the complete syntax for this command, at a command prompt type:

    dsmod group /?

Related Topics


Modify schema permissions

Microsoft Windows graphic

To modify schema permissions

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, right-click Active Directory Schema, and then click Permissions.
  3. On the Security tab, under Group or user names, click the group whose permissions you want to change.
  4. Under Permissions for Administrators, select Allow or Deny for the permissions you want to change.

Notes

  • XOX
  • XOX
  • The Active Directory Schema snap-in must be connected to the schema master to perform this procedure. The Active Directory Schema snap-in connects to the schema master by default when it is started.
  • If the Active Directory Schema snap-in is not installed, see Related Topics.

Related Topics


Add an attribute to the global catalog

Microsoft Windows graphic

To add an attribute to the global catalog

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, click Attributes.

    3. Where?

    • Active Directory Schema
    • Attributes
  3. In the details pane, right-click the attribute that you want to add to the global catalog, and then click Properties.
  4. Select the Replicate this attribute to the Global Catalog check box.

Caution

  • If the forest functional level is not set to Windows Server 2003, adding a new attribute to the global catalog will cause a full synchronization of the global catalog. In other words, when you add a new attribute to the global catalog attribute set, all attributes that were previously part of the global catalog in addition to the new attribute are immediately synchronized throughout the forest. For more information, see Related Topics.

Important

  • As a best practice, it is strongly recommended that you use global groups or universal groups instead of domain local groups when specifying permissions on domain objects replicated to the global catalog. For more information, see Related Topics.

Notes

  • XOX
  • XOX
  • The Active Directory Schema snap-in must be connected to the schema master to perform this procedure. The Active Directory Schema snap-in connects to the schema master by default when it is started.
  • If the Active Directory Schema snap-in is not installed, see Related Topics.

Related Topics


Index an attribute in Active Directory

Microsoft Windows graphic

To index an attribute in Active Directory

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, click Attributes.

    3. Where?

    • Active Directory Schema
    • Attributes
  3. In the details pane, right-click the attribute that you want to index, and then click Properties.
  4. Click Index this attribute in the Active Directory.

Notes

  • XOX
  • The Active Directory Schema snap-in must be connected to the schema master to perform this procedure. The Active Directory Schema snap-in connects to the schema master by default when it is started.
  • XOX
  • If the Active Directory Schema snap-in is not installed, see Related Topics.
  • Indexing an attribute improves the performance of queries run against the attribute.

Related Topics


Index attributes for a containerized search

Microsoft Windows graphic

To index attributes for a containerized search

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, click Attributes.

    3. Where?

    • Active Directory Schema
    • Attributes
  3. In the details pane, right-click the attribute that you want to index, and then click Properties.
  4. Select the Index this attribute for containerized searches in the Active Directory check box.

Notes

  • XOX
  • XOX
  • The Active Directory Schema snap-in must be connected to the schema master to perform this procedure. The Active Directory Schema snap-in connects to the schema master by default when it is started.
  • If the Active Directory Schema snap-in is not installed, see Related Topics.
  • To complete this procedure, you must first index the attribute. For more information, see Related topics.

Related Topics


View a schema class or attribute definition

Microsoft Windows graphic

To view a schema class or attribute definition

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, click Active Directory Schema.
  3. Do one of the following:
    • To view a class definition, in the console tree, click Classes. In the details pane, right-click the class for which you want to view the definition, and then click Properties.
    • To view an attribute definition, in the console tree, click Attributes. In the details pane, right-click the attribute for which you want to view the definition, and then click Properties.

Notes

  • XOX
  • XOX
  • If the Active Directory Schema snap-in is not installed, see Related Topics.

Related Topics


Modify a schema class or attribute definition

Microsoft Windows graphic

To modify an existing schema class or attribute definition

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, click Active Directory Schema.
  3. Do one of the following:
    • To modify a class definition, in the console tree, click Classes. In the details pane, right-click the class you want to modify, and then click Properties.
    • To modify an attribute definition, in the control tree, click Attributes. In the details pane, right-click the attribute you want to modify, and then click Properties.

Notes

  • XOX
  • XOX
  • The Active Directory Schema snap-in must be connected to the schema master to perform this procedure. The Active Directory Schema snap-in connects to the schema master by default when it is started.
  • If the Active Directory Schema snap-in is not installed, see Related Topics.

Related Topics


Add a schema class or attribute definition

Microsoft Windows graphic

To add a new schema class or attribute definition

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, click Active Directory Schema.
  3. Do one of the following:
    • To add a class definition, in the console tree, right-click Classes, click Create Class, and then follow the instructions.
    • To add an attribute definition, in the console tree, right-click Attributes, click Create Attribute, and then follow the instructions.

Notes

  • XOX
  • XOX
  • The Active Directory Schema snap-in must be connected to the schema master to perform this procedure. The Active Directory Schema snap-in connects to the schema master by default when it is started.
  • If the Active Directory Schema snap-in is not installed, see Related Topics.

Related Topics


Deactivate a class or attribute

Microsoft Windows graphic

To deactivate a class or attribute

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, click Active Directory Schema.
  3. Do one of the following:
    • To deactivate a class, in the console tree, click Classes. In the details pane, right-click the class you want to deactivate, and then click Properties.
    • To deactivate an attribute, in the console tree, click Attributes. In the details pane, right-click the attribute you want to deactivate, and then click Properties.
  4. On the General tab, clear the Class is active or Attribute is active check box, as appropriate.

Notes

  • XOX
  • XOX
  • The Active Directory Schema snap-in must be connected to the schema master to perform this procedure. The Active Directory Schema snap-in connects to the schema master by default when it is started.
  • If the Active Directory Schema snap-in is not installed, see Related Topics.
  • The status of an attribute or class is displayed in the Status column of the details pane. Once a class or attribute has been deactivated, it is considered defunct.
  • Default schema attributes or classes in the base schema cannot be deactivated. Only attributes or classes added as extensions to the base schema can be deactivated.
  • Classes and attributes added to the base schema can be deactivated without raising the forest functional level. However, they can be redefined only in forests with the forest functional level set to Windows Server 2003.
  • To view defunct classes or attributes, click Classes or Attributes, and then on the View menu, click Defunct Objects.

Related Topics


Reactivate a class or attribute

Microsoft Windows graphic

To reactivate a class or attribute

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, click Active Directory Schema.
  3. Do one of the following:
    • To reactivate a defunct class, in the console tree, click Classes. In the details pane, right-click the class you want to reactivate, and then click Properties.
    • To reactivate a defunct attribute, in the console tree, click Attributes. In the details pane, right-click the attribute you want to reactivate, and then click Properties.
  4. On the General tab, select the Class is active or Attribute is active check box, as appropriate.

Notes

  • XOX
  • XOX
  • The Active Directory Schema snap-in must be connected to the schema master to perform this procedure. The Active Directory Schema snap-in connects to the schema master by default when it is started.
  • If the Active Directory Schema snap-in is not installed, see Related Topics.
  • The status of an attribute or class is displayed in the Status column of the details pane. Once a class or attribute has been deactivated, it is considered defunct.
  • To view defunct classes or attributes, click Classes or Attributes, and then on the View menu, click Defunct Objects.

Related Topics


Reload the schema

Microsoft Windows graphic

To reload the schema

  1. Open the Active Directory Schema snap-in.
  2. In the console tree, right-click Active Directory Schema, and then click Reload the Schema.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain), the Schema Admins group or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • If the Active Directory Schema snap-in is not installed, see Related Topics.

Related Topics


Enable schema changes on a schema master running Windows 2000

Microsoft Windows Graphic

To enable schema changes on a schema master running Windows 2000

  1. Open Registry Editor.

    Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied.
  2. In Registry Editor, navigate to the Parameters registry key:

      Where?

      • HKEY_LOCAL_MACHINE
      • SYSTEM
      • CurrentControlSet
      • Services
      • NTDS
      • Parameters
  3. On the Edit menu, click New, and then click DWORD Value.
  4. Type Schema Update Allowed, and then press ENTER.
  5. Double-click the Schema Update Allowed registry key that you just created, and then, in Value data, type 1 to enable schema changes.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • To disable schema changes, in the Schema Update Allowed registry key, under Value data, type 0.
  • This procedure should only be performed on a domain controller that is running Windows 2000 and that also holds the schema master role.

Related Topics


Manage sites

  • Configure site settings
  • Configure server settings
  • Configure replication between sites


Configure site settings

  • Create a site
  • Rename a site
  • Delete a site
  • Create a subnet
  • Associate a subnet with a site
  • Delete a subnet
  • Select another licensing computer
  • Cache universal group memberships
  • Delegate control of a site
  • Connect to a forest
  • Connect to a domain controller
  • Reveal the services node


Create a site

Microsoft Windows graphic

To create a site

  1. Open Active Directory Sites and Services.
  2. Right-click the Sites folder, and then click New Site.
  3. In Name, type the name of the new site.
  4. Click a site link object, and then click OK.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • It is recommended that you use legal Domain Name System (DNS) names when you create new site names; otherwise, your site will only be accessible where a Microsoft DNS server is used. For more information about DNS names, see Related Topics.

Related Topics


Rename a site

Microsoft Windows graphic

To rename a site

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the site that you want to rename, and then click Rename.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that you want to rename
  3. Type the new site name.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • It is recommended that you use legal Domain Name System (DNS) names when you create new site names; otherwise, your site will only be accessible where a Microsoft DNS server is used. For more information about DNS names, see Related Topics.

Related Topics


Delete a site

Microsoft Windows graphic

To delete a site

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the site that you want to delete, and then click Delete.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that you want to delete

Important

  • Before a site can be deleted, any domain controller objects within the site must be deleted or moved to another site.

Notes

  • To perform this procedure, you must be a member of the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • You cannot delete the site called Default-First-Site-Name.

Related Topics


Create a subnet

Microsoft Windows graphic

To create a subnet

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click Subnets, and then click New Subnet.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Subnets
  3. In Address, type the subnet address.
  4. In Mask, type the subnet mask that describes the range of addresses included in this subnet.
  5. Under Select a site object for this subnet, click the site to associate with this subnet, and then click OK.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX

Related Topics


Associate a subnet with a site

Microsoft Windows graphic

To associate a subnet with a site

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the subnet with which you want to associate the site, and then click Properties.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Subnets
    • subnet
  3. In Site, click the site with which to associate this subnet.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX

Related Topics


Delete a subnet

Microsoft Windows graphic

To delete a subnet

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the subnet that you want to delete, and then click Delete.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Subnets
    • subnet that you want to delete

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX

Related Topics


Select another licensing computer

Microsoft Windows graphic

To select another licensing computer

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the site you want to configure.

    Where?

    • Active Directory Sites and Services
    • Sites
    • site
  3. In the details pane, right-click Licensing Site Settings, and then click Properties.
  4. On the Licensing Settings tab, click Change.
  5. In Enter the object name to select, type the computer name of the alternative licensing computer, and then click OK.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • The licensing server collects licensing information from within the site for use by the licensing administrative tool. For more information, see Related Topics.
  • Active Directory will automatically configure a licensing computer for each site. For optimal performance, the licensing computer for a site should reside within that same site. A licensing computer does not have to be a domain controller.

Related Topics


Cache universal group memberships

Microsoft Windows graphic

To cache universal group memberships

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the site in which you want to enable universal group membership caching.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • the site in which you want to enable universal group membership caching
  3. In the details pane, right-click NTDS Site Settings, and then click Properties.
  4. Select the Enable Universal Group Membership Caching check box.
  5. In Refresh cache from, click a site from which this site will refresh its cache, or accept <Default> to refresh the cache from the nearest site that has a global catalog.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX

Related Topics


Delegate control of a site

Microsoft Windows graphic

To delegate control of a site

  1. Open Active Directory Sites and Services.
  2. Right-click the container whose control you want to delegate, and then click Delegate Control to start the Delegation of Control Wizard.
  3. Follow the instructions in the Delegation of Control Wizard.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • In Active Directory Sites and Services, you can delegate control for the subnets, intersite transports, sites, and server containers. Delegating control of an object allows you to specify who has permissions to access or modify that object or its child objects.

Related Topics


Connect to a forest

Microsoft Windows graphic

To connect to a forest

  1. Open Active Directory Sites and Services.
  2. Right-click Active Directory Sites and Services, and then click Connect to Forest.
  3. In Root domain, type the root domain of the forest, and then click OK.

    This is the root domain of the first domain tree created in the forest.

Notes

  • XOX
  • XOX
  • Active Directory Sites and Services views a single forest. Change forests to view and configure Active Directory Sites and Services settings for a forest of your choosing.

Related Topics


Connect to a domain controller

Microsoft Windows graphic

To connect to a domain controller

  1. Open Active Directory Sites and Services.
  2. Right-click Active Directory Sites and Services, and then click Connect to Domain Controller.
  3. In Domain, type a domain name, or click Browse to select from the list of available domains.
  4. In Enter the name of another domain controller, click a domain controller from the list of available domain controllers, or accept the default value Any Writable Domain Controller to have a domain controller automatically selected.

Notes

  • XOX
  • XOX
  • Active Directory Sites and Services views and configures a single copy of the directory data. Change the domain controller to select an alternate domain controller whose directory data will read and modify.

Related Topics


Reveal the services node

Microsoft Windows graphic

To reveal the services node

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click Active Directory Sites and Services, point to View, and then click Show Services Node.

Notes

  • XOX
  • XOX
  • Show Services Node is a persistent setting.
  • Managing objects located in the Services container from within Active Directory Sites and Services provides limited functionality. It is recommended that you use other appropriate administrative tools, including ADSI Edit, for managing objects located in the Services container. For more information, see Related Topics.

Related Topics


Configure server settings

  • Select a query policy
  • Enable or disable a global catalog
  • Designate a preferred bridgehead server
  • Move a domain controller between sites
  • Check the replication topology
  • Delete extinct server metadata


Select a query policy

Microsoft Windows graphic

To select a query policy

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the domain controller whose query policy you want to change.

    Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller whose query policy you want to change
    • Servers
    • domain controller whose query policy you want to change
  3. In the details pane, right-click NTDS Settings, and then click Properties.
  4. On the General tab, in Query Policy, click a query policy.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the domain of the selected domain controller) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • A query policy prevents specific Lightweight Directory Access Protocol (LDAP) operations from adversely impacting the performance of the domain controller and also makes the domain controller more resilient to denial-of-service attacks.
  • To create or modify query policies, use the Ntdsutil command-line tool.

Related Topics


Enable or disable a global catalog

Microsoft Windows graphic

To enable or disable a global catalog

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the domain controller where you want to enable or disable the global catalog.

    Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller that you want to disable or enable
    • Servers
    • domain controller
  3. In the details pane, right-click NTDS Settings, and then click Properties.
  4. Select the Global Catalog check box to enable the global catalog, or clear the check box to disable the global catalog.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the domain of the selected domain controller) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Members of the Domain Admins group can always log on to the domain, even when a global catalog is not available.
  • Enabling a global catalog can cause additional replication traffic.
  • The local domain controller will not advertise itself as a global catalog until this policy has been propagated to read-only directory partitions in the domain.

Related Topics


Designate a preferred bridgehead server

Microsoft Windows graphic

To designate a preferred bridgehead server

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the domain controller that you want to make a preferred bridgehead server, and then click Properties.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller that you want to make a preferred bridgehead server
    • Servers
    • the domain controller that you want to make a preferred bridgehead server
  3. On the General tab, click the intersite transport or transports for which this computer will be a preferred bridgehead server, and then click Add.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the domain of the selected domain controller) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Assigning a bridgehead server manually can cause replication problems because it prevents the Knowledge Consistency Checker (KCC) from making an automatic failover assignment if a manually selected bridgehead server fails. For more information, see Related Topics.
  • You can establish preferred bridgehead servers for one or more protocols (such as IP or SMTP).

Related Topics


Move a domain controller between sites

Microsoft Windows graphic

To move a domain controller between sites

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the domain controller that you want to move to a different site, and then click Move.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller you want to move
    • Servers
    • domain controller to be moved
  3. In the Move Server dialog box, click the site to which you want to move the domain controller.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the domain of the selected domain controller) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • This procedure can be used to move member servers, as well as domain controllers, between sites.
  • You can also drag server objects to move them.

Related Topics


Check the replication topology

Microsoft Windows graphic

To check the replication topology

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the domain controller you want to use to check replication topology.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller whose replication topology you want to check
    • Servers
    • server you want to use to check replication topology
  3. In the details pane, right-click NTDS Settings, point to All Tasks, and then click Check Replication Topology.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the domain of the selected domain controller) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Active Directory runs the intersite topology generator on one domain controller in a site to consider the cost of intersite connections and to check if any previously available domain controllers are no longer available or if new domain controllers have been added. Then, the Knowledge Consistency Checker (KCC) uses this information to add or remove connection objects as needed for efficient replication. This process does not affect manually created connection objects. Only one domain controller per site assumes the role of the intersite topology generator.
  • To identify the intersite topology generator in each site, you can use the Dcdiag Windows Support tool available on your operating system installation CD.

Related Topics


Delete extinct server metadata

Microsoft Windows graphic

To delete extinct server metadata

  1. Open Command Prompt.
  2. Type:

    3. ntdsutil

  3. At the ntdsutil command, type:

    4. metadata cleanup

  4. At the metadata cleanup command, type:

    5. connection

  5. At the connection command, type:

    6. connect to server Server

  6. At the connection command, type:

    7. quit

  7. At the metadata cleanup command, type:

    8. select operation target

  8. At the select operation target command, type:

    9. list sites

  9. A numbered list of sites will be displayed, type:

    10. select site SiteNumber

  10. At the select operation target command, type:

    11. list domains in site

  11. A numbered list of domains in the selected site will be displayed, type:

    12. select domain DomainNumber

  12. At the select operation target command, type:

    13. list servers in site

  13. A numbered list of servers in a domain and site will be displayed, type:

    14. select server ServerNumber

  14. At the select operation target command, type:

    15. quit

  15. At the metadata cleanup command, type:

    16. remove selected server

Value | Description
Server | The DNS name of a domain controller.
SiteNumber | The number associated to the site that you want to connect to, which displays in the list.
DomainNumber | The number associated to the domain that you want to clean up, which displays in the list.
ServerNumber | The number associated to the server that you want to connect to, which displays in the list.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the domain of the selected domain controller) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • You can use this procedure to delete from the directory the metadata of a domain controller that could not be cleanly decommissioned.
  • Do not delete the metadata of existing domain controllers.
  • To clean metadata, you must first select the operation target. When selecting the operation target for a server, you must first select the site, and then the domain.

Related Topics


Configure replication between sites

  • Create a site link
  • Delete a site link
  • Create a site link bridge
  • Delete a site link bridge
  • Configure site link replication availability
  • Configure site link cost
  • Configure site link replication frequency
  • Ignore replication schedules
  • Enable or disable site link bridges
  • Add a site to a site link
  • Manually add connections
  • Force replication over a connection


Create a site link

Microsoft Windows graphic

To create a site link

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the intersite transport protocol you want the site link to use, and then click New Site Link.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport protocol you want the site link to use
  3. In Name, type the name to be given to the link.
  4. Click two or more sites to connect, and then click Add.
  5. Configure the site link's cost, schedule, and replication frequency. See Related Topics for information.

Important

  • If you create a site link that uses SMTP, you must have an enterprise certification authority (Enterprise CA) available and SMTP must be installed on all domain controllers that will use the site link.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Creating a site link between two or more sites is a way to influence replication topology. By creating a site link, you provide Active Directory with information about what connections are available, which ones are preferred, and how much bandwidth is available. Active Directory uses this information to choose times and connections for replication that will afford the best performance.

Related Topics


Delete a site link

Microsoft Windows graphic

To delete a site link

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport folder that contains the site link you want to delete.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport folder that contains the site link you want to delete
  3. In the details pane, right-click the site link you want to delete, and then click Delete.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Before deleting a site link, you should ensure that its member sites will still belong to at least one existing site link.

Related Topics


Create a site link bridge

Microsoft Windows graphic

To create a site link bridge

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the inter-site transport folder for which you want to create a new site link bridge, and then click New Site Link Bridge.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • intersite transport for which you want to create a new site link bridge
  3. In Name, type a name for the site link bridge.
  4. Click two or more site links to be bridged, and then click Add.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • If Bridge all site links is enabled (default setting), this procedure is redundant and will have no effect.
  • A site link bridge creates a chain of site links across which domain controllers from different sites in the site links can directly communicate.

Related Topics


Delete a site link bridge

Microsoft Windows graphic

To delete a site link bridge

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport folder that contains the site link bridge you want to delete.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport folder that contains the site link bridge you want to delete
  3. In the details pane, right-click the site link bridge that you want to delete, and then click Delete.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX

Related Topics


Configure site link replication availability

Microsoft Windows graphic

To configure site link replication availability

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport folder that contains the site link whose schedule you want to adjust.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport folder that contains the site link whose schedule you want to adjust
  3. In the details pane, right-click the site link whose schedule you want to adjust, and then click Properties.
  4. Click Change Schedule.
  5. Select the block of time you want to schedule, and then click Replication Not Available or Replication Available.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Replication availability schedules can be temporarily ignored by selecting Ignore schedules on the appropriate inter-site transport folder. For more information, see Related Topics.
  • By default, Simple Mail Transfer Protocol (SMTP) replication does not utilize site link availability information.

Related Topics


Configure site link cost

Microsoft Windows graphic

To configure site link cost

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport folder that contains the type of link you are going to configure.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport folder that contains the type of link you are going to configure
  3. In the details pane, right-click the site link whose cost you want to set, and then click Properties.
  4. In Cost, enter a value for the cost of replication.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • The Active Directory Knowledge Consistency Checker (KCC) considers a site link with a higher cost to be less desirable than a site link with a lower cost. When multiple paths for replication are available, the KCC prefers the site link with the lower cost.
  • You cannot apply costs directly to site link bridges.

Related Topics


Configure site link replication frequency

Microsoft Windows graphic

To configure site link replication frequency

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport folder that contains the site link you want to configure.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport folder that contains the site link you want to configure
  3. In the details pane, right-click the site link whose replication frequency you want to set, and then click Properties.
  4. In Replicate every, type the number of minutes between replications.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • The default site link replication frequency is 180 minutes.
  • The Replicate every value will be processed as the nearest multiple of 15 ranging from a minimum of 15 to a maximum of 10,080 minutes, which corresponds to one week.

Related Topics


Ignore replication schedules

Microsoft Windows graphic

To ignore replication schedules

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the intersite transport protocol that contains the site link schedules you want ignored, and then click Properties.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • the intersite transport protocol for which you want replication schedules ignored
  3. Select the Ignore schedules check box.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • When Ignore schedules is selected, any site link availability schedules that have been configured are ignored, and all site links become always available for replication. When Ignore schedules is cleared, any previously configured site link availability schedules go back into effect. If no site link availability schedules have been configured, selecting Ignore schedules has no effect.

Related Topics


Enable or disable site link bridges

Microsoft Windows graphic

To enable or disable site link bridges

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the intersite transport folder (such as IP or SMTP) for which you want to enable or disable site link bridges, and then click Properties.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • intersite transport for which you want to enable or disable link bridges
  3. Do one of the following:
    • To enable site link bridges, select the Bridge all site links check box.
    • To disable site link bridges, clear the Bridge all site links check box.

Important

  • By default, all site links are bridged. For more information about disabling this option and its affects on intersite replication, see Related Topics.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX

Related Topics


Add a site to a site link

Microsoft Windows graphic

To add a site to a site link

  1. Open Active Directory Sites and Services.
  2. In the console tree, click the inter-site transport folder that contains the site link to which you are adding the site.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • Inter-Site Transports
    • inter-site transport folder that contains the site link to which you are adding the site
  3. In the details pane, right-click the site link to which you want to add the site, and then click Properties.
  4. Click the site you want to add to this site link, and then click Add.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX

Related Topics


Manually add connections

Microsoft Windows graphic

To manually add connections

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click NTDS Settings for the domain controller for which you want to manually add a connection, and then click New Active Directory Connection.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the domain controller for which you want to manually add a connection
    • Servers
    • domain controller for which you want to manually add a connection
    • NTDS Settings
  3. In the Find Domain Controllers dialog box, click the domain controller that you want to include in the connection object.
  4. In the New Object-Connection dialog box, type a name for the new connection object.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the domain of the selected domain controller) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • Active Directory automatically creates and deletes connection objects under normal conditions.
  • If you are certain that a connection is required and that you want it to persist until it is manually removed, create a connection manually.

Related Topics


Force replication over a connection

Microsoft Windows graphic

To force replication over a connection

  1. Open Active Directory Sites and Services.
  2. In the console tree, click NTDS Settings for the server that you want to force replication.

    3. Where?

    • Active Directory Sites and Services
    • Sites
    • site that contains the connection over which you want to replicate directory information
    • Servers
    • server that you want to force replication
    • NTDS Settings
  3. In the details pane, right-click the connection over which you want to replicate directory information, and then click Replicate Now.

Notes

  • To perform this procedure, you must be a member of the Domain Admins group (in the domain of the selected domain controller) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • You can also use the repadmin and replmon command-line tools, available on your operating system installation CD, to force replication. For more information, see Related Topics.

Related Topics


Manage COM+ partitions and partition sets

  • Create a COM+ partition in Active Directory
  • Create a COM+ partition set in Active Directory
  • Map a user or organizational unit to a COM+ partition set
  • View COM+ partitions and partition sets


Create a COM+ partition in Active Directory

Microsoft Windows Graphic

To create a COM+ partition in Active Directory

  1. Open Active Directory Users and Computers.
  2. On the View menu, select Advanced Features.
  3. In the console tree, right-click ComPartitions, and then click New Partition.

    4. Where?

    • Active Directory Users and Computers
    • domain node
    • System
    • ComPartitions
  4. Under Partition Name, type a name for the new partition.

Notes

  • XOX
  • XOX
  • Once you have created a COM+ partition using Active Directory Users and Computers, you must then create an empty partition on a application server and associate it with the appropriate COM+ partition in Active Directory. For more information, see Related Topics.
  • When creating a new COM+ partition, a partition ID is automatically generated and displayed under Partition ID in the Properties dialog box. If you want to specify a different GUID for the new COM+ partition, delete the existing partition ID and type a new one.

Related Topics


Create a COM+ partition set in Active Directory

Microsoft Windows Graphic

To create a COM+ partition set in Active Directory

  1. Open Active Directory Users and Computers.
  2. On the View menu, select Advanced Features.
  3. In the console tree, right-click ComPartitionSets, and then click New Partition Set.

    4. Where?

    • Active Directory Users and Computers
    • domain node
    • System
    • ComPartitionSets
  4. Under Name and Description, type the name and description of the new partition set, and then click Next.
  5. On the Configure Partitions for New Set page, click the partitions that you want to include in the partition set, click Add, and then click Next.
  6. On the Configure Users for New Set page, click Add User and Add Org Unit to add the users and organizational units that are to be mapped to the partition set, and then click Finish.

Notes

  • XOX
  • XOX
  • By using COM+ partition sets, you can associate multiple users or organizational units with a COM+ partition set at one time instead of having to map multiple user identities or organizational units. A COM+ partition set is available to users or organizational units that are mapped to it.
  • When creating a new COM+ partition set, a partition ID is automatically generated and displayed under Partition Set ID in the Properties dialog box. If you want to specify a different GUID for the new COM+ partition set, delete the existing partition ID and type a new one.

Related Topics


Map a user or organizational unit to a COM+ partition set

Microsoft Windows Graphic

To map a user or organizational unit to a COM+ partition set

  1. Open Active Directory Users and Computers.
  2. On the View menu, select Advanced Features.
  3. Do one of the following:

    4. At the user or organizational unit

    1. In the console tree, right-click the user name or organizational unit that you want to map to a partition set, and then click Properties.
    2. On the COM+ tab, under Partition Set, click the partition set to which you want to map the user or organizational unit.

    At the COM+ partition set

    1. In the console tree, click ComPartitionSets.

      2. Where?

      • Active Directory Users and Computers
      • domain node
      • System
      • ComPartitionSets
    2. Right-click the COM+ partition set to which you want to map a user or organizational unit, and then click Configure Set Members.
    3. In the Add/Remove Users dialog box, click Add User and Add Org Unit to add the users and organizational units that you want to map to the partition set, and then click OK.

Notes

  • XOX
  • XOX
  • By using COM+ partition sets, you can associate multiple users or organizational units with a COM+ partition set at one time instead of having to map multiple user identities or organizational units. A COM+ partition set is available to users or organizational units that are mapped to it.

Related Topics


View COM+ partitions and partition sets

Microsoft Windows Graphic

To view COM+ partitions and partition sets

  1. Open Active Directory Users and Computers.
  2. On the View menu, select Advanced Features.
  3. Do one of the following:
    • To view partitions, in the console tree, click ComPartitions.

      • Where?

      • Active Directory Users and Computers
      • domain node
      • System
      • ComPartitions
    • To view partition sets, in the console tree, click ComPartitionSets.

      • Where?

      • Active Directory Users and Computers
      • domain node
      • System
      • ComPartitionSets

Notes

  • XOX
  • XOX
  • To view the properties of a COM+ partition or partition set, right-click it, and then click Properties.

Related Topics


Search Active Directory

  • Find a user account
  • Find a contact
  • Find a printer
  • Find a shared folder
  • Find a group
  • Find a computer account
  • Find an organizational unit
  • Find a domain controller
  • Perform a custom search
  • Create a saved query
  • Export or import a saved query


Find a user account

Microsoft Windows Graphic

To find a user account

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. If you want to search the entire domain, in the console tree, right-click the domain node, and then click Find.

    Or, if you know which organizational unit the user is in, in the console tree, right-click the organizational unit, and then click Find.

  3. In Name, type the name of the user you want to find.
  4. Click Find Now.

Notes

  • XOX
  • XOX
  • You can search using partial search criteria. For example, B will return all objects whose name begins with the letter B, such as Backup Operators.
  • Use the Advanced tab for more powerful search options.
  • To find a user, you can also click Find objects in Active Directory. on the toolbar.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery user parameter

Value | Description
parameter | For the list of parameters, see Dsquery.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dsquery user /?

Related Topics


Find a contact

Microsoft Windows graphic

To find a contact

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. If you want to search the entire domain, in the console tree, right-click the domain node, and then click Find.

    Or, if you know which organizational unit the contact is in, in the console tree, right-click the organizational unit, and then click Find.

  3. On the Users, Contacts, and Groups tab, in Name, type the name of the contact you want to find.
  4. Click Find Now.

Notes

  • XOX
  • XOX
  • You can search using partial search criteria. For example, B will return all objects whose name begins with the letter B, such as Backup Operators.
  • Use the Advanced tab for more powerful search options.
  • To find a contact, you can also click Find objects in Active Directory. on the toolbar.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery contact parameter

Value | Description
parameter | For the list of parameters, see Dsquery.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dsquery contact /?

Related Topics


Find a printer

Microsoft Windows graphic

To find a printer

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain node, and then click Find.
  3. In the Find list, click Printers.
  4. On the Printers tab, in Name, type the name of the printer you want to find.
  5. Click Find Now.

Notes

  • XOX
  • XOX
  • You can also click the Features tab to find a printer with particular features, or click the Advanced tab for more powerful search options.
  • To find printers, you can also click Find objects in Active Directory. on the toolbar.

Related Topics


Find a shared folder

Microsoft Windows graphic

To find a shared folder

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain node, and then click Find.
  3. In the Find list, click Shared Folders.
  4. On the Shared Folders tab, in Named, type the name of the folder you want to find.
  5. Click Find Now.

Notes

  • XOX
  • XOX
  • Use the Advanced tab for more powerful search options.
  • To find shared folders, you can also click Find objects in Active Directory. on the toolbar.

Related Topics


Find a group

Microsoft Windows Graphic

To find a group

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain node, and then click Find.
  3. On the Users, Contacts, and Groups tab, in Name, type the name of the group you want to find.
  4. Click Find Now.

Notes

  • XOX
  • XOX
  • You can search using partial search criteria. For example, B will return all objects whose name begins with the letter B, such as Backup Operators.
  • Use the Advanced tab for more powerful search options.
  • To find groups, you can also click Find objects in Active Directory. on the toolbar.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery group parameter

Value | Description
parameter | There are several attributes of a group that you can search by using this command. For the list of parameters, see Dsquery.

Notes

  • XOX
  • XOX

Related Topics


Find a computer account

Microsoft Windows Graphic

To find a computer account

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. If you want to search the entire domain, in the console tree, right-click the domain node, and then click Find.

    Or, if you know which organizational unit the computer is in, in the console tree, right-click the organizational unit, and then click Find.

  3. In Find, click Computers.
  4. In Name, type the name of the computer you want to find.

  5. To find only domain controllers, in Role, click Domain Controller.

    Or, to find only workstations and servers (not domain controllers), in Role, click Workstations and Servers.

  6. Click Find Now.

Notes

  • XOX
  • XOX
  • To configure more powerful search options, click the Advanced tab.
  • To find a computer, you can also click Find objects in Active Directory. on the toolbar.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery computer -name Name

Value | Description
Name | Searches for computers whose name attributes (value of CN attribute) matches Name.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dsquery computer /?

Related Topics


Find an organizational unit

Microsoft Windows Graphic

To find an organizational unit

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain node, and then click Find.
  3. In the Find list, click Organizational Units.
  4. Type the name of the organizational unit you want to find, and then click Find Now.

Notes

  • XOX
  • XOX
  • Use the Advanced tab for more powerful search options.
  • To find organizational units, you can also click Find objects in Active Directory. on the toolbar.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery ou parameter

Value | Description
parameter | For the list of parameters, see Dsquery.

Notes

  • XOX
  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    dsquery ou /?

Related Topics


Find a domain controller

Microsoft Windows Graphic

To find a domain controller

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click any node or folder, and then click Find.

    Or, if you know which folder contains the domain controller, right-click that folder to narrow the search to that folder.

  3. In Find, click Computers and in Role, click Domain Controller.

    If you do not know which folder contains the domain controller, in In, click the domain you want to search or click Entire Directory.

  4. Click Find Now.

Notes

  • XOX
  • XOX
  • Use the Advanced tab for more powerful search options.
  • To find a computer, you can also click Find objects in Active Directory. on the toolbar.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery server Parameter

Value | Description
Parameter | There are several attributes of a server that you can search by using this command. For the list of parameters, see Dsquery.

Notes

  • XOX
  • XOX

Related Topics


Perform a custom search

Microsoft Windows Graphic

To perform a custom search

Using the Windows interface

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain node, and then click Find.
  3. In Find, click Custom Search.
  4. Click Field, point to the kind of object for which to search, and then click the attribute of that object for which you want to specify a search value.
  5. In Condition, click the condition for your search.
  6. In Value, type the attribute value for which the search will apply the condition.
  7. Click Add to add this search condition to the custom search.
  8. Repeat steps 4 through 7 until you have added all of the desired search conditions.
  9. Click Find Now.

Notes

  • XOX
  • XOX
  • Use the Advanced tab to enter a query using LDAP syntax. For more information about LDAP, see Related Topics.
  • To start a search, you can also click Find objects in Active Directory. on the toolbar.

Using a command line

  1. Open Command Prompt.
  2. Type:

    dsquery * Parameter

Value | Description
Parameter | There are several attributes that you can search by using this command. For the list of parameters, see Dsquery. For more information about LDAP searches, see Related Topics.

Notes

  • XOX
  • XOX

Related Topics


Create a saved query

Microsoft Windows graphic

To create a saved query

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Saved Queries or any of its subfolders in which you want to save a query.

    3. Where?

    • Active Directory Users and Computers
    • Saved Queries
  3. Point to New, and then click Query.
  4. In Name, type a query name.
  5. In Description, type a query description.
  6. Click Browse to define the container from which to begin your search.

    To search all subcontainers of the selected container, select the Include subcontainers check box.

  7. Click Define Query to define your query.

Notes

  • XOX
  • XOX
  • To organize your saved queries, you can create subfolders by right-clicking Saved Query, pointing to New, and then clicking Folder.

Related Topics


Export or import a saved query

Microsoft Windows graphic

To export or import a saved query

  1. Open Active Directory Users and Computers.
  2. Do one of the following:
    • To export a saved query, in the Saved Queries folder, or a subfolder of Saved Queries, right-click the query you want to export, and then click Export Query Definition. Name the file, and then click Open.
    • To import a saved query, right-click Saved Queries, or a subfolder of Saved Queries, and then click Import Query Definition. Browse to the saved query, click it, and then click Open.

Notes

  • XOX
  • XOX

Related Topics


Concepts

This section provides general background information about Active Directory®:

  • Active Directory overview
  • Understanding Active Directory
  • Deploying Active Directory
  • Administering Active Directory
  • Resources


Active Directory overview

A directory is a hierarchical structure that stores information about objects on the network. A directory service, such as Active Directory®, provides the methods for storing directory data and making this data available to network users and administrators. For example, Active Directory stores information about user accounts, such as names, passwords, phone numbers, and so on, and enables other authorized users on the same network to access this information.

This section covers:

  • Introduction to Active Directory
  • New features for Active Directory
  • Security information for Active Directory


Introduction to Active Directory

The Active Directory® directory service can be installed on servers running XOX; XOX; and XOX. Active Directory stores information about objects on the network and makes this information easy for administrators and users to find and use. Active Directory uses a structured data store as the basis for a logical, hierarchical organization of directory information.

This data store, also known as the directory, contains information about Active Directory objects. These objects typically include shared resources such as servers, volumes, printers, and the network user and computer accounts. For more information about the Active Directory data store, see Directory data store.

Security is integrated with Active Directory through logon authentication and access control to objects in the directory. With a single network logon, administrators can manage directory data and organization throughout their network, and authorized network users can access resources anywhere on the network. Policy-based administration eases the management of even the most complex network. For more information about Active Directory security, see Security overview.

Active Directory also includes:

  • A set of rules, the schema, that defines the classes of objects and attributes contained in the directory, the constraints and limits on instances of these objects, and the format of their names. For more information about the schema, see Schema.
  • A global catalog that contains information about every object in the directory. This allows users and administrators to find directory information regardless of which domain in the directory actually contains the data. For more information about the global catalog, see The role of the global catalog.
  • A query and index mechanism, so that objects and their properties can be published and found by network users or applications. For more information about querying the directory, see Finding directory information.
  • A replication service that distributes directory data across a network. All domain controllers in a domain participate in replication and contain a complete copy of all directory information for their domain. Any change to directory data is replicated to all domain controllers in the domain. For more information about Active Directory replication, see Replication overview.
  • Support for Active Directory client software, which makes many features on Microsoft® Windows® 2000 Professional or XOX available to computers running Windows 95, Windows 98, and Windows NT® Server 4.0. To client computers not running Active Directory client software, the directory will appear like a Windows NT directory. For more information about client software, see Active Directory clients.

Note

  • You cannot install Active Directory on a server running XOX, but you can join the server to an Active Directory domain as a member server. For more information about XOX, see Overview of Windows Server 2003, Web Edition.


New features for Active Directory

With the new Active Directory® features available in XOX; XOX; and XOX, more efficient administration of the Active Directory directory service is available to you.

The following list summarizes the Active Directory features that are available by default on any domain controller running Windows Server 2003.

  • Multiple selection of user objects. Modify common attributes of multiple user objects at one time.
  • Drag-and-drop functionality. Move Active Directory objects from container to container by dragging one or more objects to a desired location in the domain hierarchy. You can also add objects to group membership lists by dragging one or more objects (including other group objects) to the target group.
  • Efficient search capabilities. Search functionality is object-oriented and provides an efficient search that minimizes network traffic associated with browsing objects. For more information, see Finding directory information.
  • Saved queries. Save commonly used search parameters for reuse in Active Directory Users and Computers. For more information, see Using saved queries.
  • Active Directory command-line tools. Run new directory service commands for administration scenarios. For more information, see Managing Active Directory from the command line.
  • InetOrgPerson class. The inetOrgPerson class has been added to the base schema as a security principal and can be used in the same manner as the user class. The userPassword attribute can also be used to set the account password. For more information, see User and computer accounts.
  • Application directory partitions. Configure the replication scope for application-specific data among domain controllers. For example, you can control the replication scope of Domain Name System (DNS) zone data stored in Active Directory so that only specific domain controllers in the forest participate in DNS zone replication. For more information, see Application directory partitions.
  • Ability to add additional domain controllers using backup media. Reduce the time it takes to add an additional domain controller in an existing domain by using backup media. For more information, see Using the Active Directory Installation Wizard.
  • Universal group membership caching. Prevent the need to locate a global catalog across a WAN when logging on by storing universal group membership information on an authenticating domain controller. For more information, see Global catalogs and sites.
  • Secure LDAP traffic. Active Directory administrative tools sign and encrypt all LDAP traffic by default. Signing LDAP traffic guarantees that the packaged data comes from a known source and that it has not been tampered with. For more information, see Connecting to domain controller running Windows 2000.
  • Different location option for user and computer accounts. You can now redirect the default location for user accounts and computer accounts created by the following earlier application programming interfaces (APIs): NetUserAdd, NetGroupAdd, and NetJoinDomain. You can redirect the locations from the Users and Computers containers to organizational units where group policies can be applied.
  • Active Directory quotas. Quotas can be specified in Active Directory to control the number of objects a user, group, or computer can own in a given directory partition. Domain Administrators and Enterprise Administrators are exempt from quotas.

New domain- and forest-wide Active Directory features

New domain- or forest-wide Active Directory features can be enabled only when all domain controllers in a domain or forest are running Windows Server 2003 and the domain functionality or forest functionality has been set to Windows Server 2003. For more information about domain and forest functionality settings, see Domain and forest functionality.

The following list summarizes the domain- and forest-wide Active Directory features that can be enabled when either a domain or forest functional level has been raised to Windows Server 2003.

  • Domain controller rename tool. Rename domain controllers without first demoting them. For more information, see Renaming domain controllers.
  • Domain rename. Rename any Windows Server 2003 domain. You can change the NetBIOS name or DNS name of any child, parent, tree or forest root domain. For more information, see Renaming domains.
  • Forest trusts. Create a forest trust to extend two-way transitivity beyond the scope of a single forest to a second forest. For more information, see Forest trusts.
  • Forest restructuring. Move existing domains to other locations in the domain hierarchy. For more information, see Renaming domains.
  • Defunct schema objects. Deactivate unnecessary classes or attributes from the schema. For more information, see Deactivating a class or attribute.
  • Dynamic auxiliary classes. Provides support for dynamically linking auxiliary classes to individual objects, and not just to entire classes of objects. In addition, auxiliary classes that have been attached to an object instance can subsequently be removed from the instance.
  • Global catalog replication improvements. Preserves the synchronization state of the global catalog when an administrative action results in an extension of the partial attribute set. This minimizes the replication traffic as a result of a partial attribute set extension by only transmitting attributes that were added. For more information, see Global catalog replication.
  • Replication enhancements. Linked value replication allows individual group members to be replicated across the network instead of treating the entire group membership as a single unit of replication. For more information about linked value replication, see How replication works. In addition, new spanning tree algorithms make replication more efficient, as well as more scalable across a larger number of domains and sites in both Windows 2000 and Windows Server 2003 forests. For more information, see Replication overview.
  • User access control to resources between domains or forests. Block users in a domain or forest from accessing resources in another domain or forest, and then allow selective access by setting the Allow to authenticate access control entry (ACE) on a local resource for the user or group object. For more information, see Accessing resources across domains or Accessing resources across forests.


Security information for Active Directory

Active Directory® provides a secure directory environment for your organization using built-in logon authentication and user authorization, which are core features of the Local Security Authority (LSA). Logon authentication and user authorization are available by default and provide immediate protection for network access and network resources.

For information about additional security tools and features that you can use to further secure Active Directory, see Securing Active Directory and Best practices.

Protecting access to the network

Active Directory requires confirmation of the identity of a user before allowing access to the network, a process known as authentication. Users only need to provide a single sign-on to the domain (or to trusted domains) to gain access to the network. Once Active Directory confirms the identity of the user, the LSA on the authenticating domain controller generates an access token that determines what level of access that user has on network resources. For more information about the authentication process, see Access control in Active Directory and Authentication.

Active Directory supports a number of secure Internet-standard protocols and authentication mechanisms used to prove identity upon logon, including Kerberos V5, X.509 v3 certificates, smart cards, public key infrastructure (PKI) and Lightweight Directory Access Protocol (LDAP) using Secure Sockets Layer (SSL).

Authentication between domains occurs through trusts. A trust is a relationship established between two or more domains to allow users in one domain to be authenticated by a domain controller in another domain.

Trust relationships can be transitive or nontransitive but must always be present in order for users in one domain to access shared resources in another domain. For more information, see Trusts.

In addition to securing network access through authentication, Active Directory helps to protect shared resources by facilitating user authorization. Once a user logon has been authenticated by Active Directory, the user rights assigned to the user through security groups and the permissions assigned on the shared resource will determine if the user will be authorized to access that resource. This authorization process protects shared resources from unauthorized access and permits access to only authorized users or groups.

For more information about user rights and security groups, see Group types. For more information about the user rights assigned to default groups, see Default groups. For more information about authorization, see "Designing an Authorization Strategy" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

For more information about authentication, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/) For more information about authorization and access control, see "Authorization and Access Control" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Understanding Active Directory

Active Directory is an implementation of Internet standard directory and naming protocols. It uses a database engine for transactional support and supports a variety of application programming interface standards.

This section covers:

  • Securing Active Directory
  • Access control in Active Directory
  • Active Directory naming
  • Directory data store
  • Directory access protocol
  • User and computer accounts
  • Object names
  • Organizational units
  • Active Directory server roles
  • Active Directory clients
  • Understanding domains and forests
  • Understanding groups
  • Understanding trusts
  • Understanding sites and replication
  • Understanding the global catalog
  • Interoperating with DNS and Group Policy
  • Understanding schema


Securing Active Directory

Active Directory provides a secure directory environment for your organization using built-in logon authentication and user authorization. To further secure Active Directory once it has been deployed, consider the following precautions and recommendations.

For general security information about Active Directory, see Security information for Active Directory.

For more information about authentication, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/) For more information about authorization, see "Authorization and Access Control" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

Important

  • Physical access to a domain controller can provide a malicious user unauthorized access to encrypted passwords. Therefore, it is recommended that all domain controllers be locked in a secured room with limited public access. In addition, you should limit membership in the Enterprise Admins, Domain Admins, Account Operators, Server Operators, Print Operators, and Backup Operators groups to trusted personnel in your organization. For more information about domain controllers and groups, see Domain controllers and Default groups.
To | Use
Manage the security relationship between two forests and simplify security administration and authentication across forests. | Forest trusts See Forest trusts.
Force domain users to use strong passwords. | Group Policy See Strong passwords.
Enable audit policy. Auditing event logs can notify you of actions that could pose a security risk. | Group Policy See Auditing policy.
Assign user rights to new security groups so you can specifically define a user's administrative role in the domain. | Group Policy See Assign user rights to security groups in Active Directory.
Enforce account lockouts on user accounts and decrease the possibility of an attacker compromising your domain through repeated logon attempts. | Group Policy See User and computer accounts.
Enforce password history on user accounts and decrease the possibility of an attacker compromising your domain. | Group Policy See Enforce password history.
Enforce minimum and maximum password ages on user accounts and decrease the possibility of an attacker compromising your domain. | Group Policy See Minimum password age, Maximum password age.
Verify and authenticate the validity of each user through the use of public key cryptography. | Public key infrastructure See Public key infrastructure.
Promote a secure operating environment by running your computer without administrative credentials except when required. | Run as See Using Run as.
Restrict user, group, and computer access to shared resources and filter Group Policy settings. | Security groups See Security groups.
Prevent attacks from malicious users who might try to grant elevated user rights to another user account. | SID filtering See "Using Security Identifier (SID) Filtering to Prevent Elevation of Privilege Attacks" at the Microsoft Web site. (http://www.microsoft.com/)
Provide tamper-resistant user authentication and e-mail security. | Smart cards See Smart card overview.
Use strong encryption techniques to secure account password information on local computers, member servers, or domain controllers. | Syskey See The system key utility.


Access control in Active Directory

Administrators can use access control to manage user access to shared resources for security purposes. In Active Directory, access control is administered at the object level by setting different levels of access, or permissions, to objects, such as Full Control, Write, Read, or No Access. Access control in Active Directory defines how different users can use Active Directory objects. By default, permissions on objects in Active Directory are set to the most secure setting.

The elements that define access control permissions on Active Directory objects include security descriptors, object inheritance, and user authentication.

Security descriptors

Access control permissions are assigned to shared objects and Active Directory objects to control how different users can use each object. A shared object, or shared resource, is an object that is intended to be used over a network by one or more users and includes files, printers, folders, and services. Both shared objects and Active Directory objects store access control permissions in security descriptors.

A security descriptor contains two access control lists (ACLs) used to assign and track security information for each object: the discretionary access control list (DACL) and the system access control list (SACL).

  • Discretionary access control lists (DACLs). DACLs identify the users and groups that are assigned or denied access permissions on an object. If a DACL does not explicitly identify a user, or any groups that a user is a member of, the user will be denied access to that object. By default, a DACL is controlled by the owner of an object or the person who created the object, and it contains access control entries (ACEs) that determine user access to the object.
  • System access control lists (SACLs). SACLs identify the users and groups that you want to audit when they successfully access or fail to access an object. Auditing is used to monitor events related to system or network security, to identify security breaches, and to determine the extent and location of any damage. By default, a SACL is controlled by the owner of an object or the person who created the object. A SACL contains access control entries (ACEs) that determine whether to record a successful or failed attempt by a user to access a object using a given permission, for example, Full Control and Read.

    For more information about auditing, see Auditing settings on objects.

To view DACLs and SACLs on Active Directory objects using Active Directory Users and Computers, on the View menu, click Advanced Features to access the Security tab for each object. For more information, see To assign, change, or remove permissions on Active Directory objects or properties. You can also use the DSACLS support tool to manage access control lists in Active Directory. For more information, see Active Directory support tools.

By default, DACLs and SACLs are associated with every Active Directory object, which reduces attacks to your network by malicious users or any accidental mistakes made by domain users. However, if a malicious user obtains a user name and password of any account with administrative credentials to Active Directory, your forest will be vulnerable to attack. For this reason, consider renaming or disabling the default administrator account and following the best practices as described in Best practices.

Object inheritance

By default, Active Directory objects inherit ACEs from the security descriptor located in their parent container object. Inheritance enables the access control information defined at a container object in Active Directory to apply to the security descriptors of any subordinate objects, including other containers and their objects. This eliminates the need to apply permissions each time a child object is created. If necessary, you can change the inherited permissions. However, as a best practice, avoid changing the default permissions or inheritance settings on Active Directory objects. For more information, see Best practices for assigning permissions on Active Directory objects and Changing inherited permissions.

User authentication

Active Directory also authenticates and authorizes users, groups, and computers to access objects on the network. The Local Security Authority (LSA) is the security subsystem responsible for all interactive user authentication and authorization services on a local computer. The LSA is also used to process authentication requests made through the Kerberos V5 protocol or NTLM protocol in Active Directory. For more information about Kerberos authentication, see Kerberos V5 authentication. For more information about NTLM authentication, see NTLM authentication.

Once the identity of a user has been confirmed in Active Directory, the LSA on the authenticating domain controller generates a user access token and associates a security ID (SID) with the user.

  • Access token. When a user is authenticated, LSA creates a security access token for that user. An access token contains the user's name, the groups to which that user belongs, a SID for the user, and all of the SIDs for the groups to which the user belongs. If you add a user to a group after the user access token has been issued, the user must log off and log on again before the access token will be updated.
  • Security ID (SID). Active Directory automatically assigns SIDs to security principal objects at the time they are created. Security principals are accounts in Active Directory that can be assigned permissions such as computer, group, or user accounts. Once a SID is issued to the authenticated user, it is attached to the access token of the user.

The information in the access token is used to determine a user's level of access to objects whenever the user attempts to access them. The SIDs in the access token are compared with the list of SIDs that make up the DACL for the object to ensure that the user has sufficient permission to access the object. This is because the access control process identifies user accounts by SID rather than by name.

Important

  • When a domain controller provides an access token to a user, the access token only contains information about membership in domain local groups if the domain local groups are local to the domain controller's domain. For domain directory objects replicated in the global catalog, this fact requires certain security considerations. For more information, see Global catalog replication.

For more information about authentication, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

For more information about access control and permissions, see Access control overview. For more information about authorization and access control, see "Authorization and Access Control" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

For information about additional security measures that can be implemented to protect Active Directory, see Securing Active Directory and Security information for Active Directory.


Active Directory naming

Active Directory domain names are usually the full Domain Name System (DNS) name of the domain. However, for backward compatibility, each domain also has a pre-Windows 2000 name for use by computers running pre-Windows 2000 operating systems. The pre-Windows 2000 domain name can be used to log on to a Windows Server 2003 domain from computers running pre-Windows 2000 operating systems using the DomainName\UserName format. This same format can also be used to log on to a Windows Server 2003 domain from computers running Windows 2000, XOX, or servers running Windows Server 2003. Users can also log on to computers running Windows 2000, XOX, or servers running Windows Server 2003 using the user principal name (UPN) associated with their user account.

User accounts

In Active Directory, each user account has a user logon name, a pre-Windows 2000 user logon name (security account manager account name), and a UPN suffix. The administrator enters the user logon name and selects the UPN suffix when creating the user account. Active Directory suggests a pre-Windows 2000 user logon name using the first 20 bytes of the user logon name. Administrators can change the pre-Windows 2000 logon name at any time.

In Active Directory, each user account has a UPN based on IETF RFC 822, Standard for the Format of ARPA Internet Text Messages. The UPN is composed of the user logon name and the UPN suffix joined by the @ sign.

Note

  • Do not add the @ sign to the user logon name or to the UPN suffix. Active Directory automatically adds it when it creates the UPN. A UPN that contains more than one @ sign is invalid.

Important

  • Windows NT 4.0 and earlier domains allowed the use of a period (.) at the end of a user logon name as long as the user logon name did not consist solely of period characters. Windows Server 2003 domains do not allow the use of a period or multiple periods at the end of a user logon name.

The second part of the UPN, the UPN suffix, identifies the domain in which the user account is located. This UPN suffix can be the DNS domain name, the DNS name of any domain in the forest, or it can be an alternative name created by an administrator and used just for log on purposes. This alternative UPN suffix does not need to be a valid DNS name.

In Active Directory, the default UPN suffix is the DNS name of the domain in which user account created. In most cases, this is the domain name registered as the enterprise domain on the Internet. Using alternative domain names as the UPN suffix can provide additional logon security and simplify the names used to log on to another domain in the forest.

For example, if your organization uses a deep domain tree, organized by department and region, domain names can get quite long. The default user UPN for a user in that domain might be sales.westcoast.microsoft.com. The logon name for a user in that domain would be user@sales.westcoast.microsoft.com. Creating a UPN suffix of "microsoft" would allow that same user to log on using the much simpler logon name of user@microsoft. For more information about user accounts, see User and computer accounts and Object names.

You can add or remove UPN suffixes using Active Directory Domains and Trusts. For more information, see To add user principal name suffixes.

Computer accounts

Each computer account created in Active Directory has a relative distinguished name, a pre-Windows 2000 computer name (security account manager account name), a primary DNS suffix, a DNS host name, and a service principal name (SPN). The administrator enters the computer name when creating the computer account. This computer name is used as the Lightweight Directory Access Protocol (LDAP) relative distinguished name.

Active Directory suggests the pre-Windows 2000 name using the first 15 bytes of the relative distinguished name. The administrator can change the pre-Windows 2000 name at any time.

The DNS name for a host is called a full computer name and is a DNS fully qualified domain name (FQDN). The full computer name is a concatenation of the computer name (the first 15 bytes of the SAM account name of the computer account without the "$" character) and the primary DNS suffix (the DNS domain name of the domain in which the computer account exists). It is listed on the Computer Name tab in System Properties in Control Panel.

By default, the primary DNS suffix portion of the FQDN for a computer must be the same as the name of the Active Directory domain where the computer is located. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces (ADSI) or the Lightweight Directory Access Protocol (LDAP).

For more information, see Object names and User and computer accounts.

The service principal name (SPN) is a multivalue attribute. It is usually built from the DNS name of the host. The SPN is used in the process of mutual authentication between the client and the server hosting a particular service. The client finds a computer account based on the SPN of the service to which it is trying to connect. The SPN can be modified by members of the Domain Admins group.


Directory data store

The Active Directory directory service uses a data store for all directory information. This data store is often referred to as the directory. The directory contains information about objects such as users, groups, computers, domains, organizational units, and security policies. This information can be published for use by users and administrators.

The directory is stored on domain controllers and can be accessed by network applications or services. A domain can have one or more domain controllers. Each domain controller has a copy of the directory for the entire domain in which it is located. Changes made to the directory on one domain controller are replicated to other domain controllers in the domain, domain tree, or forest. Active Directory uses four distinct directory partition types to store and copy different types of data. Directory partitions contain domain, configuration, schema, and application data. This storage and replication design provides directory information to users and administrators throughout the domain.

Directory data is stored in the Ntds.dit file on the domain controller. It is recommended that you store this file on an NTFS partition. For more information about the tool used to manage the Active Directory database and log files, see Files in Ntdsutil. Private data is stored securely, and public directory data is stored on a shared system volume where it can be replicated to other domain controllers in the domain. For more information about replication, see Replication overview.

Directory data replicated between domain controllers includes the following:

  • Domain data

    • The domain data holds information about objects within a domain. This is information such as e-mail contacts, user and computer account attributes, and published resources that are of interest to administrators and users.

    For example, when a user account is added to your network, a user account object and attribute data are stored in the domain data. When changes to your organization's directory objects occur, such as object creation, deletion, or attribute modification, this data is stored in the domain data.

  • Configuration data

    • The configuration data describes the topology of the directory. This configuration data includes a list of all domains, trees, and forests and the locations of the domain controllers and global catalogs.

  • Schema data

    • The schema is the formal definition of all object and attribute data that can be stored in the directory. Domain controllers running Windows Server 2003 include a default schema that defines many object types, such as user and computer accounts, groups, domains, organizational units, and security policies. Administrators and programmers can extend the schema by defining new object types and attributes or by adding new attributes for existing objects. Schema objects are protected by access control lists, ensuring that only authorized users can alter the schema.

    For more information, see Schema.

  • Application data

    • Data stored in the application directory partition is intended to satisfy cases where information needs to be replicated but not necessarily on a global scale. Application directory partitions are not part of the directory data store by default; they must be created, configured, and managed by the administrator.

    For more information, see Application directory partitions.

Note

  • If a domain controller is also a global catalog, it stores a subset of the directory data for all other domains in the forest. For more information about domain controllers, see Domain controllers. For more information about the global catalog, see The role of the global catalog.

Quotas and directory partitions

Quotas, a new feature with domain controllers running Windows Server 2003, determine the number of objects that can be owned in a given directory partition by a security principal. (The owner of an object is usually, but not always, the creator of the object.) Quotas can help prevent the denial of service that can occur if a security principal accidentally, or intentionally, creates objects until the affected domain controller runs out of storage space.

Quotas are specified and administered for each directory partition separately. The schema partition, however, has no quotas. On a given directory partition, you can assign quotas for any security principal, including users, inetOrgPersons, computers, and groups. Members of the Domain Admins and Enterprise Admins groups are exempt from quotas. In some cases, a security principal might be covered by multiple quotas. For example, a user might be assigned an individual quota, and also belong to one or more security groups that also have quotas assigned to them. In such cases, the effective quota is the maximum of the quotas assigned to the security principal.

If a security principal is not assigned a quota either directly or through a group membership, a default quota on the partition governs the security principal. If you do not explicitly set the default quota on a given partition, the default quota of that partition is unlimited (ie, there is no limit).

Tombstone objects owned by a security principal are also counted as part of the quota consumption of that security principal. For each partition, you can specify a tombstone quota factor to determine the percentage weight given to a tombstone object in quota accounting. For example, if the tombstone quota factor for a given partition is set to 25 (or 25%), then a tombstone object on the partition is counted as 0.25 (or ¼) of a normal object. If a quota of 100 is specified for a user on this partition, then the user could own a maximum of 100 normal objects, or a maximum 400 tombstone objects. The default tombstone quota factor for each partition is initially set to 100 (or 100%), meaning that normal and tombstones objects are weighted equally.

The following example illustrates how quotas can be used. Consider the domain "sales.northwindtraders.com." Because this domain supports a lot of printing activity, the domain contains several print servers that each support 1,000 or more print queues. Initially, the default quota of the sales.northwindtraders.com domain partition is set to unlimited. To help control the number of objects created and owned, the administrator specifies a default quota of 500. Now, each user can own a maximum of 500 objects on the partition. Because print queues are directory objects that are created and owned by the respective print servers, the new default quota of 500 limits each print server to 500 print queues. To remove this constraint, the administrator creates a group called "Print Servers" and adds the computer account of each print server to the group. The administrator then specifies a quota of 2,000 for the Print Servers group. Now, each print server can support its original number of print queues, while the default quota continues to prevent excess object creation by all other security principals.

Only domain controllers running Windows Server 2003 can enforce quotas. Quotas are enforced only on originating directory operations; quotas are not enforced on replicated operations. In order for quotas to be fully effective for any given directory partition, all domain controllers that contain a writable copy of that partition must be running Windows Server 2003. Therefore, for quotas to be effective on a domain directory partition, all domain controllers in that domain must be running Windows Server 2003. For quotas to be effective on the configuration partition, all domain controllers in the forest must by running Windows Server 2003.

For information about creating, modifying, and querying quotas, default quotas, and tombstone quota factors, see dsadd quota, dsmod quota, dsadd quota, and dsquery quota.


Directory access protocol

Active Directory clients must communicate with domain controllers when logging on to the network and when searching for shared resources. Access to domain controllers and global catalogs is performed using the Lightweight Directory Access Protocol (LDAP).

Lightweight Directory Access Protocol

LDAP is a communication protocol designed for use on TCP/IP networks. LDAP defines how a directory client can access a directory server and how the client can perform directory operations and share directory data. LDAP standards are established by working groups of the Internet Engineering Task Force (IETF). Active Directory implements the LDAP attribute draft specifications and the IETF standards for LDAP versions 2 and 3.

As its name implies, LDAP is designed as an efficient method for accessing directory services without the complexity of other directory service protocols. Because LDAP defines what operations can be performed to query and modify information in a directory and how information in a directory can be securely accessed, you can use LDAP to find or enumerate directory objects and to query or administer Active Directory.

LDAP and interoperability

LDAP is an open Internet standard. By using LDAP, Active Directory enables interoperability with other vendor directory services. Active Directory support for LDAP includes an LDAP provider object as part of Active Directory Service Interfaces (ADSI). ADSI supports the C-binding application programming interfaces for LDAP. Other directory service applications can be easily modified to access information in Active Directory by using ADSI and LDAP.

For more information about LDAP, see the Internet Engineering Task Force at the Internet Engineering Task Force Web site.

Note

  • XOX


User and computer accounts

Active Directory user accounts and computer accounts represent a physical entity such as a computer or person. User accounts can also be used as dedicated service accounts for some applications.

User accounts and computer accounts (as well as groups) are also referred to as security principals. Security principals are directory objects that are automatically assigned security IDs (SIDs), which can be used to access domain resources. A user or computer account is used to:

  • Authenticate the identity of a user or computer.

    A user account enables a user to log on to computers and domains with an identity that can be authenticated by the domain. For information about authentication, see Access control in Active Directory. Each user who logs on to the network should have his or her own unique user account and password. To maximize security, you should avoid multiple users sharing one account.

  • Authorize or deny access to domain resources.

    Once the user has been authenticated, the user is authorized or denied access to domain resources based on the explicit permissions assigned to that user on the resource. For more information, see Security information for Active Directory.

  • Administer other security principals.

    Active Directory creates a foreign security principal object in the local domain to represent each security principal from a trusted external domain. For more information about foreign security principals, see When to create an external trust.

  • Audit actions performed using the user or computer account.

    Auditing can help you monitor account security. For more information about auditing, see Auditing overview.

User accounts

The Users container located in Active Directory Users and Computers displays the three built-in user accounts: Administrator, Guest, and HelpAssistant. These built-in user accounts are created automatically when you create the domain.

Each built-in account has a different combination of rights and permissions. The Administrator account has the most extensive rights and permissions over the domain, while the Guest account has limited rights and permissions. The table below describes each default user account on domain controllers running Windows Server 2003.

Default user account | Description
Administrator account The Administrator account has full control of the domain and can assign user rights and access control permissions to domain users as necessary. This account must be used only for tasks that require administrative credentials. It is recommended that you set up this account with a strong password. For more information, see Strong passwords. For additional security considerations for accounts with administrative credentials, see Best practices.

The Administrator account is a default member of the Administrators, Domain Admins, Enterprise Admins, Group Policy Creator Owners, and Schema Admins groups in Active Directory. The Administrator account can never be deleted or removed from the Administrators group, but it can be renamed or disabled. Because the Administrator account is known to exist on many versions of Windows, renaming or disabling this account will make it more difficult for malicious users to try and gain access to it. For more information about how to rename or disable a user account, see To rename a local user account or To disable or enable a user account.

The Administrator account is the first account created when you set up a new domain using the Active Directory Installation Wizard.

Important

  • When the Administrator account is disabled, it can still be used to gain access to a domain controller using Safe Mode.
Guest account The Guest account is used by people who do not have an actual account in the domain. A user whose account is disabled (but not deleted) can also use the Guest account. The Guest account does not require a password.

You can set rights and permissions for the Guest account just like any user account. By default, the Guest account is a member of the built-in Guests group and the Domain Guests global group, which allows a user to log on to a domain. The Guest account is disabled by default, and it is recommended that it stay disabled.
HelpAssistant account (installed with a Remote Assistance session) | The primary account used to establish a Remote Assistance session. This account is created automatically when you request a Remote Assistance session and has limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service and will be automatically deleted if no Remote Assistance requests are pending. For more information about Remote Assistance, see Administering Remote Assistance.

Securing user accounts

If built-in account rights and permissions are not modified or disabled by a network administrator, they could be used by a malicious user (or service) to illegally log on to a domain using the Administrator or Guest identity. A good security practice for protecting these accounts is to rename or disable them. Because it retains its security ID (SID), a renamed user account retains all its other properties, such as its description, password, group memberships, user profile, account information, and any assigned permissions and user rights.

To obtain the security of user authentication and authorization, create an individual user account for each user who will participate on your network by using Active Directory Users and Computers. Each user account (including the Administrator and Guest account) can then be added to a group to control the rights and permissions assigned to the account. Using accounts and groups that are appropriate for your network ensures that users logging on to a network can be identified and can access only the permitted resources.

You can help defend your domain from attackers by requiring strong passwords and implementing an account lockout policy. Strong passwords reduce the risk of intelligent guessing and dictionary attacks on passwords. For more information, see Strong passwords and Best practices for passwords.

An account lockout policy decreases the possibility of an attacker compromising your domain through repeated logon attempts. This is because an account lockout policy determines how many failed logon attempts a user account can have before it is disabled. For more information, see To apply or modify account lockout policy.

For more information about securing user accounts, see Securing Active Directory.

Account options

Each Active Directory user account has a number of account options that determine how someone logging on with that particular user account is authenticated on the network. You can use the following options to configure password settings and security-specific information for user accounts:

Account option | Description
User must change password at next logon | Forces a user to change their password the next time the user logs on to the network. Use this option when you want to ensure that the user will be the only person to know their password.
User cannot change password | Prevents a user from changing their password. Use this option when you want to maintain control over a user account, such as for a guest or temporary account.
Password never expires | Prevents a user password from expiring. It is recommended that Service accounts should have this option enabled and should use strong passwords. For more information about strong passwords, see Strong passwords.
Store passwords using reversible encryption | Allows a user to log on to a Windows network from Apple computers. If a user is not logging on from an Apple computer, this option should not be used. For more information, see Store passwords using reversible encryption.
Account is disabled | Prevents a user from logging on with the selected account. Many administrators use disabled accounts as templates for common user accounts. For more information, see To disable or enable a user account.
Smart card is required for interactive logon | Requires that a user possess a smart card to log on to the network interactively. The user must also have a smart card reader attached to their computer and a valid personal identification number (PIN) for the smart card. When this option is selected, the password for the user account is automatically set to a random and complex value and the Password never expires account option is set. For more information about smart cards, see Logging on to a computer with a smart card and Authentication process.
Account is trusted for delegation Allows a service running under this account to perform operations on behalf of other user accounts on the network. A service running under a user account (otherwise known as a service account) that is trusted for delegation can impersonate a client to gain access to resources on the computer where the service is running or on other computers. In a forest set to the Windows Server 2003 functional level, this setting is found on the Delegation tab, and is only available for accounts that have been assigned service principal names (SPNs), as set using the setspn command from the Windows Support Tools. This is a security-sensitive capability and should be cautiously assigned. For more information, see To allow a user to be trusted for delegation and Delegating authentication.

This option is only available on domain controllers running Windows Server 2003 where the domain functionality is set to Windows 2000 mixed or Windows 2000 native. On domain controllers running Windows Server 2003 where the domain functional level is set to Windows Server 2003, the Delegation tab is used to configure delegation settings. The Delegation tab only appears for accounts which have an assigned SPN. For more information about domain functionality, see Domain and forest functionality. For more information about configuring delegation in a Windows Server 2003 domain, see To allow a user to be trusted for delegation.
Account is sensitive and cannot be delegated | Allows control over a user account, such as for a guest or temporary account. This option can be used if this account cannot be assigned for delegation by another account.
Use DES encryption types for this account | Provides support for the Data Encryption Standard (DES). DES supports multiple levels of encryption, including MPPE Standard (40-bit), MPPE Standard (56-bit), MPPE Strong (128-bit), IPSec DES (40-bit), IPSec 56-bit DES, and IPSec Triple DES (3DES). For more information about DES encryption, see Data encryption.
Do not require Kerberos preauthentication | Provides support for alternate implementations of the Kerberos protocol. Domain controllers running Windows 2000 or Windows Server 2003 can use other mechanisms to synchronize time. Because preauthentication provides additional security, use caution when enabling this option. For more information about Kerberos, see Kerberos V5 authentication.

InetOrgPerson accounts

Active Directory provides support for the InetOrgPerson object class and its associated attributes defined in RFC 2798. The InetOrgPerson object class is used in several non-Microsoft LDAP and X.500 directory services to represent people within an organization.

Support for InetOrgPerson makes migrations from other LDAP directories to Active Directory more efficient. The InetOrgPerson object is derived from the user class and can be used as a security principal just like the user class. For information about creating an inetOrgPerson user account, see To create a new user account.

When the domain functional level has been set to Windows Server 2003, you can set the userPassword attribute on InetOrgPerson and user objects as being the effective password just like you can with the unicodePwd attribute.

Computer accounts

Every computer running Windows NT, Windows 2000, XOX, or a server running Windows Server 2003 that joins a domain has a computer account. Similar to user accounts, computer accounts provide a means for authenticating and auditing computer access to the network and to domain resources. Each computer account must be unique.

Note

  • Computers running Windows 95 and Windows 98 do not have advanced security features and are not assigned computer accounts.

User and computer accounts can be added, disabled, reset, and deleted using Active Directory Users and Computers. A computer account can also be created when you join a computer to a domain. For more information about user and computer accounts, see Active Directory naming and Object names.

When the domain functional level has been set to Windows Server 2003, a new lastLogonTimestamp attribute is used to track the last logon time of a user or computer account. This attribute is replicated within the domain and can provide you with important information regarding the history of a user or computer.


Object names

Every object in Active Directory is an instance of a class defined in the schema. Each class has attributes that ensure:

  • Unique identification of each object (instance of a class) in a directory data store
  • Backward compatibility with security IDs used in Windows NT 4.0 and earlier
  • Compatibility with LDAP standards for directory object names

For more information about schema, classes, and attributes, see Schema.

Each object in Active Directory can be referenced by several different names. Active Directory creates a relative distinguished name and a canonical name for each object based upon information that was provided when the object was created or modified. Each object can also be referenced by its distinguished name, which is derived from the relative distinguished name of the object and all of its parent container objects.

  • The LDAP relative distinguished name uniquely identifies the object within its parent container. For example, the LDAP relative distinguished name of a computer named my computer is CN=mycomputer. Relative distinguished names must be unique in that users cannot have the same name within an organizational unit.
  • The LDAP distinguished name is globally unique. For example, the distinguished name of a computer named mycomputer in the MyOrganizationalUnit organizational unit in the microsoft.com domain is CN=mycomputer, OU=MyOrganizationalUnit, DC=microsoft, DC=com.
  • The canonical name is constructed the same way as the distinguished name, but it is represented using a different notation. The canonical name of the computer in the previous example would be Microsoft.com/MyOrganizationalUnit/mycomputer.

Security principal objects are Active Directory objects that are assigned security IDs (SIDs) and can be used to log on to the network and can be assigned access to domain resources. An administrator needs to provide names for security principal objects (user accounts, computer accounts, and groups) that are unique within a domain.

Consider what occurs when a new user account is added to your directory. You provide a name the user must use to log on to the network, the name of the domain that contains the user account, and other descriptive data, such as first name, last name, telephone number and so on (called attributes). All this information is recorded in the directory.

The names of security principal objects can contain all Unicode characters except the special LDAP characters defined in RFC 2253. This list of special characters includes: a leading space; a trailing space; and any of the following characters: # , + " \ < > ;

Security principal names must conform to the following guidelines:

Type of account name | Maximum size | Special limitations
User account | Computers running Windows Server 2003 and Windows 2000 can use a user principal name (UPN) for a user account. Computers running Windows NT 4.0 and earlier are limited to 20 characters or 20 bytes depending upon the character set; individual characters may require more than one byte. | A user account cannot consist solely of periods (.) or spaces, or end in a period. Any leading periods or spaces are cropped. Use of the @ symbol is not supported with the logon format for Windows NT 4.0 and earlier, which is DomainName\UserName. Windows 2000 logon names are unique to the domain and Windows Server 2003 logon names are unique within the forest.
Computer account | NetBIOS = 15 characters, or 15 bytes depending upon the character set; individual characters may require more than one byte. DNS = 63 characters or 63 bytes depending upon the character set and 255 characters for a fully qualified domain name (FQDN) individual characters may require more than one byte. | A computer account cannot consist solely of numbers, periods (.), or spaces. Any leading periods or spaces are cropped.
Group account | 63 characters, or 63 bytes depending upon the character set; individual characters may require more than one byte. | A group account cannot consist solely of numbers, periods (.), or spaces. Any leading periods or spaces are cropped.

Note

  • If the administrator changes the default security settings, then it is possible to use computer names containing more than 15 characters. For more information, see Active Directory naming.

From the information provided by the person who creates the security principal object, Active Directory generates a security ID (SID), and a globally unique ID used to identify the security principal. Active Directory also creates an LDAP relative distinguished name, based on the security principal name. An LDAP distinguished name and a canonical name are derived from the relative distinguished name and the names of the domain and container contexts in which the security principal object is created.

If your organization has several domains, it is possible to use the same user name or computer name in different domains. The SID, globally unique ID, LDAP distinguished name, and canonical name generated by Active Directory will uniquely identify each user, computer, or group in the forest. If the security principal object is renamed or moved to a different domain, the SID, LDAP relative distinguished name, LDAP distinguished name, and canonical name will change, but the globally unique ID generated by Active Directory will not change.

Security principal objects, such as user accounts, may be renamed, moved, or contained within a nested domain hierarchy. To reduce the effect of renaming, moving, or assigning user account names within a nested domain hierarchy, Active Directory provides a method for simplifying user logon names. For information about user logon names, see Active Directory naming and To add user principal name suffixes, and User and computer accounts.


Organizational units

A particularly useful type of directory object contained within domains is the organizational unit. Organizational units are Active Directory containers into which you can place users, groups, computers, and other organizational units. An organizational unit cannot contain objects from other domains.

An organizational unit is the smallest scope or unit to which you can assign Group Policy settings or delegate administrative authority. Using organizational units, you can create containers within a domain that represent the hierarchical, logical structures within your organization. You can then manage the configuration and use of accounts and resources based on your organizational model. For more information about Group Policy settings, see Group Policy.

Organizational unit hierarchy within a domain

As shown in the figure, organizational units can contain other organizational units. A hierarchy of containers can be extended as necessary to model your organization's hierarchy within a domain. Using organizational units will help you minimize the number of domains required for your network.

You can use organizational units to create an administrative model that can be scaled to any size. A user can have administrative authority for all organizational units in a domain or for a single organizational unit. An administrator of an organizational unit does not need to have administrative authority for any other organizational units in the domain. For more information about delegating administrative authority, see Delegating administration.


Active Directory server roles

Computers that function as servers within a domain can have one of two roles: member server or domain controller. A server that is not in a domain is a stand-alone server.

Member servers

A member server is a computer that:

  • Runs an operating system in the Windows 2000 Server family or the Windows Server 2003 family.
  • Belongs to a domain.
  • Is not a domain controller.

A member server does not process account logons, participate in Active Directory replication, or store domain security policy information.

Member servers typically function as the following types of servers: file servers, application servers, database servers, Web servers, certificate servers, firewalls, and remote access servers. For more information about server roles, see Server roles.

The following security-related features are common to all member servers:

  • Member servers adhere to Group Policy settings that are defined for the site, domain, or organizational unit.
  • Access control for resources that are available on a member server.
  • Member server users have assigned user rights.
  • Member servers contain a local security account database, the Security Accounts Manager (SAM).

Domain controllers

A domain controller is a computer that:

  • Runs an operating system in the Windows 2000 Server family or the Windows Server 2003 family.
  • Uses Active Directory to store a read-write copy of the domain database, participate in multimaster replication, and authenticate users.

Domain controllers store directory data and manage communication between users and domains, including user logon processes, authentication, and directory searches. Domain controllers synchronize directory data using multimaster replication, ensuring consistency of information over time. For more information about multimaster replication, see Replication overview.

Active Directory supports multimaster replication of directory data between all domain controllers in a domain; however, multimaster replication is not appropriate for some directory data replication. In this case, a domain controller, called the operations master, will process data. In an Active Directory forest, there are at least five different operations master roles that are assigned to one or more domain controllers. For more information about operations masters, see Operations master roles.

As the needs of your computing environment change, you might want to change the role of a server. Using the Active Directory Installation Wizard, you can install Active Directory on a member server to make it a domain controller, or you can remove Active Directory from a domain controller to make it a member server. For more information about domain controllers, see Domain controllers.

Note

  • You cannot install Active Directory on a computer running XOX, but you can join the computer to an Active Directory domain as a member server. For more information about XOX, see Overview of Windows Server 2003, Web Edition.


Active Directory clients

With the Active Directory client, many of the Active Directory features available on Windows 2000 Professional or XOX are available to computers running Windows 95, Windows 98, and Windows NT 4.0.

  • Site awareness

    You can log on to the domain controller that is closest to the client in the network. For more information, see Locating a domain controller.

  • Active Directory Service Interfaces (ADSI)

    You can use scripting to Active Directory. ADSI also provides a common programming API to Active Directory programmers.

  • Distributed File System (DFS)

    You can access DFS shared resources on servers running Windows 2000 and Windows Server 2003.

  • NTLM version 2 authentication

    You can use the improved authentication features in NTLM version 2.

    For more information about enabling NTML version 2, see article Q239869, "How to Enable NTLM 2 Authentication," in the Microsoft Knowledge Base (http://www.microsoft.com/).

  • Active Directory Windows Address Book (WAB) property pages

    You can change properties, such as phone number and address, on user object pages.

  • Active Directory search capability

    From the Start button, you can locate printers and people in a Windows 2000 Server or Windows Server 2003 domain.

    For information about publishing printers in Active Directory, see article Q234619, "Publishing a Printer in Windows 2000 Active Directory," in the Microsoft Knowledge Base (http://www.microsoft.com/).

Windows 2000 Professional and XOX provide functionality that the Active Directory client on Windows 95, Windows 98, and Windows NT 4.0 does not, including Kerberos V5 support; Group Policy or IntelliMirror support; and service principal name (SPN), or mutual authentication. You can take advantage of these additional features by upgrading to Windows 2000 Professional or XOX.

To install the Active Directory client, see the Active Directory client page at the Microsoft Web site (http://www.microsoft.com/).


Understanding Domains and Forests

This section covers:

  • Domain controllers
  • Renaming domain controllers
  • Connecting to domain controllers running Windows 2000
  • Domains
  • Renaming domains
  • Domain and forest functionality
  • Raising domain and forest functional levels
  • Application directory partitions
  • Application directory partitions and domain controller demotion
  • Managing application directory partitions
  • Operations master roles
  • Transferring operations master roles
  • Responding to operations master failures


Domain controllers

When you create the first domain controller in your organization, you are also creating the first domain, the first forest, the first site, and installing Active Directory. Domain controllers running Windows Server 2003 store directory data and manage user and domain interactions, including user logon processes, authentication, and directory searches. Domain controllers are created by using the Active Directory Installation Wizard. For more information, see Using the Active Directory Installation Wizard.

Note

  • You cannot install Active Directory on a computer running XOX, but you can join the computer to an Active Directory domain as a member server. For more information about XOX, see Overview of Windows Server 2003, Web Edition.

When using domain controllers in your organization, you will want to think about how many domain controllers you’ll need, the physical security of those domain controllers, a plan for backing up the domain data, and upgrading domain controllers.

Determining the number of domain controllers you need

A small organization using a single local area network (LAN) might need only one domain with two domain controllers for high availability and fault tolerance. A larger organization with many network locations will need one or more domain controllers in each site to provide high availability and fault tolerance.

If your network is divided into sites, it is often good practice to put at least one domain controller in each site to enhance network performance. When users log on to the network, a domain controller must be contacted as part of the logon process. If clients must connect to a domain controller located in a different site, the logon process can take a long time. For more information, see Replication between sites.

By creating a domain controller in each site, user logons are processed more efficiently within the site. For information about how to create additional domain controllers, see To create an additional domain controller.

To optimize network traffic, you can also configure domain controllers to receive directory replication updates only during off-peak hours. For information about how to schedule site replication, see To configure site link replication availability.

The best network performance is available when the domain controller at a site is also a global catalog. This way, the server can fulfill queries about objects in the entire forest. However, enabling many domain controllers as global catalogs can increase the replication traffic on your network. For more information about the global catalog, see The role of the global catalog. For more information about adding global catalogs to sites, see Global catalogs and sites.

In domains with more than one domain controller, do not enable the domain controller holding the infrastructure master role as a global catalog. For more information, see Operations master roles.

Physical security

Physical access to a domain controller can provide a malicious user unauthorized access to encrypted passwords. For this reason, it is recommended that all domain controllers in your organization be locked in a secured room with limited public access. You can use additional security measures such as Syskey for extra protection on domain controllers. For more information about Syskey, see The system key utility.

Backing up domain controllers

You can back up domain directory partition data and data from other directory partitions by using Backup, which is included with the Windows Server 2003 family, from any domain controller in a domain. By using the backup tool on a domain controller, you can:

  • Back up Active Directory while the domain controller is online.
  • Back up Active Directory using batch file commands.
  • Back up Active Directory to removable media, an available network drive, or a file.
  • Back up other system and data files.

When you use the backup tool on a domain controller it will automatically back up all of the system components and all of the distributed services upon which Active Directory is dependent. This dependent data, which includes Active Directory, is known collectively as the System State data.

On a domain controller running Windows Server 2003, the System State data consists of the system startup files; the system registry; the class registration database of COM+ (an extension to the Component Object Model); the SYSVOL directory; Certificate Services database (if installed); Domain Name System (if installed); Cluster service (if installed); and Active Directory. It is recommended that you regularly back up System State data.

For general information about the System State, see System State data. For more information about how to back up the System State, see To back up System State data. For more information about how to restore a System State backup, see To restore System State data.

You can install Active Directory on a server running Windows Server 2003 by using a restored backup taken from a domain controller running Windows Server 2003. For more information, see Creating additional domain controllers.

Upgrading domain controllers

On domain controllers running Windows NT 4.0, you will first need to upgrade the primary domain controller (PDC) to successfully upgrade the domain. Once the PDC has been upgraded, you can upgrade the backup domain controllers (BDCs). For more information, see Upgrading from a Windows NT domain.

If you currently have a Windows 2000 forest that does not have any domain controllers running Windows Server 2003, you will need to prepare the forest and the target domain before you can upgrade domain controllers running Windows 2000. For more information, see Upgrading from a Windows 2000 domain.


Renaming domain controllers

The ability to rename domain controllers running Windows Server 2003 provides you with the flexibility to make changes in a Windows Server 2003 domain whenever the need arises. Rename a domain controller to:

  • Restructure your network for organizational and business needs.
  • Make management and administrative control easier.

When you rename a domain controller, you must ensure that there will be no interruption in the ability of clients to locate or authenticate to the renamed domain controller, except when the domain controller is restarted. This is required for renaming the domain controller. For more information about renaming a domain controller, see To rename a domain controller.

Another requirement for renaming a domain controller is that the domain functional level must be set to Windows Server 2003. For more information, see Domain and forest functionality.

The new name of the domain controller is automatically updated to Domain Name System (DNS) and Active Directory. Once the new name propagates to DNS and Active Directory, clients are then capable of locating and authenticating to the renamed domain controller. DNS and Active Directory replication latency may delay client ability to locate or authenticate to the renamed domain controller. The length of time this takes depends on specifics of your network and the replication topology of your particular organization.

During replication latency, clients may not be able to access the newly renamed domain controller. This might be acceptable for clients that try to locate and authenticate to a particular domain controller since other domain controllers should be available to process the authentication request.


Connecting to domain controllers running Windows 2000

When you need to connect to a domain controller running Windows 2000 from a domain controller running Windows Server 2003, a number of Active Directory administrative tools are available, such as Active Directory Domains and Trusts.

The following Windows Server 2003 Active Directory administrative tools will sign and encrypt all LDAP traffic by default:

  • Active Directory Users and Computers
  • Active Directory Sites and Services
  • Active Directory Domains and Trusts
  • Active Directory Schema
  • ADSI Edit
  • Dsrm.exe
  • Dsmove.exe
  • Dsadd.exe
  • Dsmod.exe
  • Dsget.exe
  • Dsquery.exe

Signing LDAP traffic guarantees that the packaged data comes from a known source and that it has not been tampered with. The Active Directory administrative tools in Windows 2000 do not sign and encrypt all LDAP traffic by default. In order to maintain a secure network, it is strongly recommended that you upgrade all domain controllers running Windows 2000 to Service Pack 3 or later.

You can use the corresponding Active Directory administrative tools in Windows 2000 to manage Windows 2000 domain controllers that do not have the Windows 2000 Server Service Pack 3 or later installed. However, traffic is not signed and encrypted by LDAP on domain controllers running Windows 2000.

Although it is not recommended, you can disable encrypted and signed LDAP traffic used with Active Directory administrative tools on a server running Windows Server 2003 or on a computer running XOX that has the Windows Server 2003 Administration Tools Pack installed. For more information, see To disable signed or encrypted LDAP traffic.


Domains

Domains are units of replication. All of the domain controllers in a particular domain can receive changes and replicate those changes to all other domain controllers in the domain. Each domain in Active Directory is identified by a Domain Name System (DNS) domain name and requires one or more domain controllers. If your network requires more than one domain, you can easily create multiple domains.

One or more domains that share a common schema and global catalog are referred to as a forest. The first domain in a forest is referred to as the forest root domain. For more information about forests, see Creating a new forest. If multiple domains in the forest have contiguous DNS domain names, then the structure is referred to as a domain tree. For more information, see Active Directory naming and Creating a new domain tree.

A single domain can span multiple physical locations or sites and can contain millions of objects. Site structure and domain structure are separate and flexible. A single domain can span multiple geographical sites, and a single site can include users and computers belonging to multiple domains. For more information, see Sites overview.

A domain provides several benefits:

  • Organizing objects.

    You do not need to create separate domains merely to reflect your company's organization of divisions and departments. Within a domain, you can use organizational units for this purpose. Using organizational units helps you manage the accounts and resources in the domain. You can then assign Group Policy settings and place users, groups, and computers into the organizational units. Using a single domain greatly simplifies administrative overhead. For more information, see Organizational units.

  • Publishing resources and information about domain objects.

    • A domain stores only the information about objects located in that domain, so by creating multiple domains, you are partitioning or segmenting the directory to better serve a disparate user base. When using multiple domains, you can scale the Active Directory directory service to accommodate your administrative and directory publishing requirements. For more information, Publishing resources.

  • Applying a Group Policy object to the domain consolidates resource and security management.

    A domain defines a scope or unit of policy. A Group Policy object (GPO) establishes how domain resources can be accessed, configured, and used. These policies are applied only within the domain and not across domains. For more information about applying GPOs, see Group Policy.

  • Delegating authority eliminates the need for a number of administrators with broad administrative authority.

    • Using delegated authority in conjunction with Group Policy objects and group memberships enables you to assign an administrator rights and permissions to manage objects in an entire domain or in one or more organizational units within the domain. For more information about delegating administrative control, see Delegating administration.

  • Security policies and settings (such as user rights and password policies) do not cross from one domain to another.

    Each domain has its own security policies and trust relationships with other domains. However, the forest is the final security boundary. For more information, see Creating a new forest.

  • Each domain stores only the information about the objects located in that domain.

    • By partitioning the directory this way, Active Directory can scale to very large numbers of objects.

Creating a domain

You create a domain by creating the first domain controller for a domain. To do this, install Active Directory on a member server running Windows Server 2003 by using the Active Directory Installation Wizard. The wizard uses the information that you provide to create the domain controller and create the domain within the existing domain structure of your organization. Depending on the existing domain structure, the new domain could be the first domain in a new forest, the first domain in a new domain tree, or a child domain of an existing domain tree. For more information, see Creating a new forest, Creating a new domain tree, and Creating a new child domain.

A domain controller provides the Active Directory directory service to network users and computers, stores directory data, and manages user and domain interactions, including user logon processes, authentication, and directory searches. Every domain must contain at least one domain controller. For more information, see Domain controllers.

After you create the first domain controller for a domain, you can create additional domain controllers in an existing domain for fault tolerance and high availability of the directory. For more information, see Creating additional domain controllers.

Planning for multiple domains

Some reasons to create more than one domain are:

  • Different password requirements between departments or divisions
  • Massive numbers of objects
  • Decentralized network administration
  • More control of replication

Although using a single domain for an entire network has several advantages, to meet additional scalability, security, or replication requirements you may consider creating one or more domains for your organization. Understanding how directory data is replicated between domain controllers will help you plan the number of domains needed by your organization. For more information about replication, see How replication works.

Removing a domain

In order to remove a domain, you must first remove Active Directory from all of the domain controllers associated with that domain. Once Active Directory has been removed from the last domain controller the domain will be removed from the forest and all of the information in that domain will be deleted. A domain can only be removed from the forest if it has no child domains. If this is the last domain in the forest, removing this domain will also delete the forest.

For more information about how to remove a domain, see To remove a domain.

Caution

  • Removing a domain will result in the permanent loss of amy data contained in that domain. This includes all user, group, and computer accounts.

Before removing Active Directory from a domain controller, you should first remove any application directory partitions from that domain controller. For more information, see Application directory partitions and To create or delete an application directory partition.

Trust relationships between domains

Trust relationships are automatically created between adjacent domains (parent and child domains) when a domain is created in Active Directory. In a forest, a trust relationship is automatically created between the forest root domain and any tree root domains or child domains that are subordinate to the forest root domain. Because these trust relationships are transitive, users and computers can be authenticated between any domains in the forest. For more information about trust relationships, see Trust transitivity.

When upgrading a Windows NT domain to a Windows Server 2003 domain, the existing one-way trust relationship between that domain and any other domains remains intact. This includes all trusts with other Windows NT domains. If you are creating a new Windows Server 2003 domain and want trust relationships with any Windows NT domains, you must create external trusts with those domains. For more information about external trusts, see When to create an external trust.


Renaming domains

The ability to rename a domain provides you with the flexibility to make important changes to your forest structure and namespace as the needs of your organization change. Renaming domains can accommodate acquisitions, mergers, name changes, or reorganizations. Domain rename allows you to:

  • Change the Domain Name System (DNS) and NetBIOS names of any domain in the forest (including the forest root domain).
  • Restructure the position of any domain in the forest (except the forest root domain).

You can only rename domains in a forest where all of the domain controllers are running Windows Server 2003 and the forest functional level has been raised to Windows Server 2003. For more information, see Domain and forest functionality.

Forest restructuring

Using domain rename, you can also restructure the hierarchy of domains in your forest so that a domain residing in one domain tree can be moved to another domain tree. Restructuring a forest allows you to move a domain anywhere within the forest in which it resides (except the forest root domain). This includes the ability to move a domain so that it becomes the root of its own domain tree.

You can use the domain rename utility (Rendom.exe) to rename or restructure a domain. The Rendom.exe utility can be found in the Valueadd\Msft\Mgmt\Domren directory on the operating system installation CD. A domain rename will affect every domain controller in your forest and is a multistep process that requires a detailed understanding of the operation. For more information, see the Domain Rename Tool page at the Microsoft Web site. (http://www.microsoft.com/)


Domain and forest functionality

Domain and forest functionality, introduced in Windows Server 2003 Active Directory, provides a way to enable domain- or forest-wide Active Directory features within your network environment. Different levels of domain functionality and forest functionality are available depending on your environment.

If all domain controllers in your domain or forest are running Windows Server 2003 and the functional level is set to Windows Server 2003, all domain- and forest-wide features are available. When Windows NT 4.0 or Windows 2000 domain controllers are included in your domain or forest with domain controllers running Windows Server 2003, Active Directory features are limited. For more information about how to enable domain- or forest-wide features, see Raising domain and forest functional levels.

The concept of enabling additional functionality in Active Directory exists in Windows 2000 with mixed and native modes. Mixed-mode domains can contain Windows NT 4.0 backup domain controllers and cannot use Universal security groups, group nesting, and security ID (SID) history capabilities. When the domain is set to native mode, Universal security groups, group nesting, and SID history capabilities are available. Domain controllers running Windows 2000 Server are not aware of domain and forest functionality.

Domain functionality

Domain functionality enables features that will affect the entire domain and that domain only. Four domain functional levels are available: Windows 2000 mixed (default), Windows 2000 native, Windows Server 2003 interim, and Windows Server 2003. By default, domains operate at the Windows 2000 mixed functional level.

The following table lists the domain functional levels and their corresponding supported domain controllers.

Domain functional level | Domain controllers supported
Windows 2000 mixed (default) | Windows NT 4.0 Windows 2000 Windows Server 2003 family
Windows 2000 native | Windows 2000 Windows Server 2003 family
Windows Server 2003 interim | Windows NT 4.0 Windows Server 2003 family
Windows Server 2003 | Windows Server 2003 family

Once the domain functional level has been raised, domain controllers running earlier operating systems cannot be introduced into the domain. For example, if you raise the domain functional level to Windows Server 2003, domain controllers running Windows 2000 Server cannot be added to that domain.

The following table describes the domain-wide features that are enabled for three of the domain functional levels. For information about the Windows Server 2003 interim functional level, see Upgrading from a Windows NT domain.

Domain feature | Windows 2000 mixed | Windows 2000 native | Windows Server 2003
Domain controller rename tool For more information, see Renaming domain controllers. | Disabled | Disabled | Enabled
Update logon timestamp For more information about the lastLogonTimestamp attribute, see User and computer accounts. | Disabled | Disabled | Enabled
User password on InetOrgPerson object For more information about InetOrgPerson objects, see User and computer accounts. | Disabled | Disabled | Enabled
Universal Groups For more information, see Group types and Group scope. | Enabled for distribution groups. Disabled for security groups. | Enabled Allows both security and distribution groups. | Enabled Allows both security and distribution groups.
Group Nesting For more information, see Nesting groups. | Enabled for distribution groups. Disabled for security groups, except for domain local security groups that can have global groups as members. | Enabled Allows full group nesting. | Enabled Allows full group nesting.
Converting Groups For more information, see Converting groups. | Disabled No group conversions allowed. | Enabled Allows conversion between security groups and distribution groups. | Enabled Allows conversion between security groups and distribution groups.
SID history | Disabled | Enabled Allows migration of security principals from one domain to another. | Enabled Allows migration of security principals from one domain to another.

Forest functionality

Forest functionality enables features across all the domains within your forest. Three forest functional levels are available: Windows 2000 (default), Windows Server 2003 interim, and Windows Server 2003. By default, forests operate at the Windows 2000 functional level. You can raise the forest functional level to Windows Server 2003.

The following table lists the forest functional levels and their corresponding supported domain controllers:

Forest functional level | Domain controllers supported
Windows 2000 (default) | Windows NT 4.0 Windows 2000 Windows Server 2003 family
Windows Server 2003 interim | Windows NT 4.0 Windows Server 2003 family
Windows Server 2003 | Windows Server 2003 family

Once the forest functional level has been raised, domain controllers running earlier operating systems cannot be introduced into the forest. For example, if you raise the forest functional level to Windows Server 2003, domain controllers running Windows 2000 Server cannot be added to the forest.

If you are upgrading your first Windows NT 4.0 domain so that it becomes the first domain in a new Windows Server 2003 forest, you can set the domain functional level to Windows Server 2003 interim. For more information, see Upgrading from a Windows NT domain.

The following table describes the forest-wide features that are enabled for the Windows 2000 and Windows Server 2003 forest functional levels.

Forest feature | Windows 2000 | Windows Server 2003
Global catalog replication improvements For more information, see Global catalog replication. | Enabled if both replication partners are running Windows Server 2003. Otherwise, disabled. | Enabled
Defunct schema objects For more information, see Deactivating a class or attribute. | Disabled | Enabled
Forest trusts For more information, see Forest trusts. | Disabled | Enabled
Linked value replication For more information, see How replication works. | Disabled | Enabled
Domain rename For more information, see Renaming domains. | Disabled | Enabled
Improved Active Directory replication algorithms For more information, see Replication overview. | Disabled | Enabled
Dynamic auxiliary classes. For more information, see New features for Active Directory. | Disabled | Enabled
InetOrgPerson objectClass change For more information about InetOrgPerson objects, see User and computer accounts. | Disabled | Enabled


Raising domain and forest functional levels

When Active Directory is installed on a server running Windows Server 2003, a set of basic Active Directory features is enabled by default. For more information about the new default features, see New features for Active Directory.

In addition to the basic Active Directory features on individual domain controllers, there are new domain- and forest-wide Active Directory features available when all domain controllers in a domain or forest are running Windows Server 2003.

To enable the new domain-wide features, all domain controllers in the domain must be running Windows Server 2003, and the domain functional level must be raised to Windows Server 2003. For information about raising the domain functional level, see To raise the domain functional level.

To enable new forest-wide features, all domain controllers in the forest must be running Windows Server 2003, and the forest functional level must be raised to Windows Server 2003. Before raising the forest functional level to Windows Server 2003, verify that all domains in the forest are set to the domain functional level of Windows 2000 native or Windows Server 2003. Note that domains that are set to the domain functional level of Windows 2000 native will automatically be raised to Windows Server 2003 at the same time the forest functional level is raised to Windows Server 2003. For information about raising the forest functional level, see To raise the forest functional level.


Application directory partitions

An application directory partition is a directory partition that is replicated only to specific domain controllers. A domain controller that participates in the replication of a particular application directory partition hosts a replica of that partition. Only domain controllers running Windows Server 2003 can host a replica of an application directory partition.

Applications and services can use application directory partitions to store application-specific data. Application directory partitions can contain any type of object, except security principals. TAPI is an example of a service that stores its application-specific data in an application directory partition.

Application directory partitions are usually created by the applications that will use them to store and replicate data. For testing and troubleshooting purposes, members of the Enterprise Admins group can manually create or manage application directory partitions using the Ntdsutil command-line tool.

One of the benefits of an application directory partition is that, for redundancy, availability, or fault tolerance, the data in it can be replicated to different domain controllers in a forest. The data can be replicated to a specific domain controller or any set of domain controllers anywhere in the forest. This differs from a domain directory partition in which data is replicated to all domain controllers in that domain. Storing application data in an application directory partition instead of in a domain directory partition may reduce replication traffic because the application data is only replicated to specific domain controllers. Some applications may use application directory partitions to replicate data only to servers where the data will be locally useful.

Another benefit of application directory partitions is that applications or services that use Lightweight Directory Access Protocol (LDAP) can continue using it to access and store their application data in Active Directory. For more information, see Managing application directory partitions.

Application directory partition naming

An application directory partition is part of the overall forest namespace just like a domain directory partition. It follows the same Domain Name System (DNS) and distinguished names naming conventions as a domain directory partition. An application directory partition can appear anywhere in the forest namespace that a domain directory partition can appear.

There are three possible application directory partition placements within your forest namespace:

  • A child of a domain directory partition.
  • A child of an application directory partition.
  • A new tree in the forest.

If you created an application directory partition called example1 as a child of the microsoft.com domain, the DNS name of the application directory partition would be example1.microsoft.com. The distinguished name of the application directory partition would be dc=example1, dc=microsoft, dc=com.

If you then created an application directory partition called example2 as a child of example1.microsoft.com, the DNS name of the application directory partition would be example2.example1.microsoft.com and the distinguished name would be dc=example2, dc=example1, dc=microsoft, dc=com.

If the domain microsoft.com was the root of the only domain tree in your forest, and you created an application directory partition with the DNS name of example1 and the distinguished name of dc=example1, this application directory partition is not in the same tree as the microsoft.com domain. This application directory partition would be the root of a new tree in the forest.

Domain directory partitions cannot be children of an application directory partition. For example, if you created an application directory partition with the DNS name of example1.microsoft.com, you could not create a domain with the DNS name of domain.example1.microsoft.com.

Application directory partition replication

The Knowledge Consistency Checker (KCC) automatically generates and maintains the replication topology for all application directory partitions in the enterprise. When an application directory partition has replicas in more than one site, those replicas follow the same intersite replication schedule as the domain directory partition.

Notes

  • Objects stored in an application directory partition are never replicated to the global catalog as read-only replicas. Any domain controller running Windows Server 2003 can hold a replica, including global catalogs.
  • Additionally, if an application requests data through the global catalog port, that query will not return any objects from an application directory partition, even if the computer hosting the application directory partition is also hosting the global catalog. This is done so that LDAP queries to different global catalogs will not return inconsistent results because the application directory partition is replicated to only one of the global catalogs.

Security descriptor reference domain

Every container and object on the network has a set of access control information attached to it. Known as a security descriptor, this information controls the type of access allowed by users, groups, and computers. If the object or container is not assigned a security descriptor by the application or service that created it, then it is assigned the default security descriptor for that object class as defined in the schema. This default security descriptor is ambiguous in that it may assign members of the Domain Admins group read permissions to the object, but it does not specify to what domain the domain administrators belong. When this object is created in a domain naming partition, that domain naming partition is used to specify which Domain Admins group actually is assigned read permission. For example, if the object is created in mydomain.microsoft.com then members of the mydomain Domain Admins group would be assigned read permission.

When an object is created in an application directory partition, the definition of the default security descriptor is difficult because an application directory partition can have replicas on different domain controllers belonging to different domains. Because of this potential ambiguity, a default security descriptor reference domain is assigned when the application directory partition is created.

The default security descriptor reference domain defines what domain name to use when an object in the application directory partition needs to define a domain value for the default security descriptor. The default security descriptor reference domain is assigned at the time of creation.

If the application directory partition is a child of a domain directory partition, by default, the parent domain directory partition becomes the security descriptor reference domain. If the application directory partition is a child object of another application directory partition, the security descriptor reference domain of the parent application directory partition becomes the reference domain of the new, child, application directory partition. If the new application directory partition is created as the root of a new tree, then the forest root domain is used as the default security descriptor reference domain.

You can manually specify a security reference domain using Ntdsutil. However, if you plan to change the default security descriptor reference domain of a particular application directory partition, you should do so before creating the first instance of that partition. To do this, you must prepare the cross-reference object and change the default security reference domain before completing the application directory partition creation process. For information about precreating the cross-reference object, see To prepare a cross-reference object. For information about changing the default security reference domain, see To set an application directory partition reference domain.


Application directory partitions and domain controller demotion

If a domain controller holds a replica of an application directory partition, then you must remove the domain controller from the replica set of the application directory partition or delete the application directory partition before you can demote the domain controller.

If a domain controller holds the last replica of a particular application directory partition, then you must delete the application directory partition before you can demote the domain controller.

The Active Directory Installation Wizard will not remove a replica or delete an application directory partition programmatically. You must decide when it is safe to delete the last replica of a particular partition.

Before deleting the last replica of an application directory partition, identify the applications that use the application directory partition, determine if it is safe to delete the last replica, identify the partition deletion tool provided by the application, and then remove the application directory partition by using the tool provided or by using the Ntdsutil command-line tool.

Identify the applications that use the application directory partition

To determine what application directory partitions are hosted on a computer, refer to the list on the first page of the Active Directory Installation Wizard. If the list does not provide enough information to identify the programs using a particular application directory partition, you may be able to identify them in one of the following ways:

  • Speak to a member of the Enterprise Admins group.
  • Consult the network change control records for your organization.
  • Use LDP or ADSI Edit to view the data contained in the partition. For more information about these tools, see the Active Directory Programmer's Guide at the Microsoft Web site. (http://www.microsoft.com/)

Determine if it is safe to delete the last replica

Removing the last replica of an application directory partition will result in the permanent loss of any data contained in the partition. If you have identified the applications using the application directory partition, consult the documentation provided with those applications to determine if there is any reason to keep the data. If the applications that use the application directory partition are out of service, it is probably safe to remove the partition.

If it is not safe to delete the last replica, or if you cannot determine whether or not it is safe, and you must demote the domain controller holding the last replica of a particular application directory partition, follow these steps: Add a replica of the partition on another domain controller, force the replication of the contents of the application directory partition to the domain controller holding the new replica, and then remove the replica of the partition on the domain controller to be demoted. For more information, see To add or remove an application directory partition replica.

Identify the partition deletion tool provided by the application

Most applications that create application directory partitions provide a utility to remove the partitions. When possible, always delete an application directory partition using the utility provided. For example, to delete a TAPI partition, use the Tapicfg.exe command-line tool. For more information about TAPI and removing TAPI application directory partitions, see Telephony.

Remove the application directory partition using the tool provided or use Ntdsutil

Refer to the application's documentation for information about removing application directory partitions that were created and used by that application.

Caution

  • If possible, use the application's tool for managing its application directory partitions. The application may keep other data in addition to Active Directory managed data for the application directory partitions. By using Ntdsutil, the two sets of data could cause a conflict.

If you cannot identify the application that created the application directory partition, or if your application does not provide a means to delete application directory partitions that it created, you can use the Ntdsutil command-line tool. To do this, see To create or delete an application directory partition.

For information about demoting a domain controller, see To demote a domain controller. For general information about application directory partitions, see Application directory partitions.


Managing application directory partitions

You can use the following tools to create, delete, or manage application directory partitions.

  • application-specific tools from the application vendor
  • Ntdsutil command-line tool
  • LDP
  • Active Directory Service Interfaces (ADSI)

For information about creating and managing application directory partitions with ADSI, see Active Directory Service Interfaces (ADSI) at the Microsoft Web site (http://www.microsoft.com/) and the Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/). For information about LDP, see Administration tools for the Active Directory schema.

For information about the Ntdsutil command-line tool, see Ntdsutil.

The following provides information about using Ntdsutil to create and manage application directory partitions.

Creating an application directory partition

When you create an application directory partition, you are creating the first instance of this partition. You can create an application directory partition by using the create nc option in the domain management menu of Ntdsutil. When creating an application directory partition using LDP or ADSI, provide a description in the description attribute of the domain DNS object that indicates the specific application that will use the partition. For example, if the application directory partition will be used to store data for a Microsoft accounting program, the description could be Microsoft accounting application. Ntdsutil does not facilitate the creation of a description. For more information, see To create or delete an application directory partition.

Deleting an application directory partition

When you delete an application directory partition, you are removing all replicas of that partition from your forest. You can delete an application directory partition by using the delete nc command in the domain management menu of Ntdsutil. The deletion process will need to replicate to all domain controllers that contain a replica of the application directory partition before the deletion process is complete. Any data that is contained in the application directory partition will be lost.

The Active Directory Promotion Wizard (Dcpromo) cannot demote a domain controller if that domain controller holds a copy of an application directory partition. For more information, see To create or delete an application directory partition.

Adding and removing a replica of an application directory partition

An application directory partition replica is an instance of an partition on another domain controller. The information in the application directory partition is replicated between the domain controllers. Application directory partition replicas are created for either redundancy or data access purposes. You can add a replica of an application directory partition by using the add nc replica command in the domain management menu of Ntdsutil. You can remove an application directory partition replica by using the delete nc replica command in the domain management menu of Ntdsutil. For more information, see To add or remove an application directory partition replica.

Setting application directory partition reference domain

The security descriptor reference domain defines a domain name for the default security descriptor for objects in the application directory partition. By default, the security descriptor reference domain is the parent domain of the application directory partition. If the application directory partition is a child of another application directory partition, the default security descriptor reference domain is the security descriptor reference domain of the parent application directory partition. If the application directory partition has no parent, the forest root domain becomes the default security descriptor reference domain. You can use Ntdsutil to change the default security descriptor reference domain. For more information, see To set an application directory partition reference domain.

Setting replication notification delays

Changes made to a particular directory partition on a particular domain controller are replicated to the other domain controllers that contain that directory partition. The domain controller on which the change was made notifies its replication partners that it has a change. You can configure how long the domain controller will wait to send the change notification to its first replication partner. You can also configure how long it waits to send the subsequent change notification to its remaining replication partners. These delays can be set for any directory partition (including domain directory partitions) on a particular domain controller. For more information, see To set a notification delay.

Displaying application directory partition information

Any domain controller that holds a replica of a particular directory partition (including application directory partitions) is said to be a member of the replica set for that directory partition. You can use Ntdsutil to list the domain controllers that are members of a particular replica set for an application directory partition. An addition of a domain controller to the replica set attribute on the cross-reference object does not create the replica, but it will display when the list nc replica command is used in Ntdsutil. The creation of the instance must replicate before the creation of the replica is complete. For more information, see To display application directory partition information.

Delegating the creation of application directory partitions

There are two things that happen when creating an application directory partition:

  • Creation of the cross-reference object.
  • Creation of the application directory partition root node.

Normally only members of the Enterprise Admins group can create an application directory partition. However, it is possible for a member of the Enterprise Admins group to prepare a cross-reference object for the application directory partition and to delegate the rest of the process to someone with more limited permissions.

The cross-reference object for an application directory partition holds several valuable pieces of information, including the domain controllers that are to have a replica of this partition and the security descriptor reference domain. The partition root node is the Active Directory object at the root of the partition

The Enterprise Admin can create the cross-reference object then delegate to a person or group with less permissions the right to create the application directory partition root node. Both creation of the cross-reference object and the application directory partition root node can be accomplished using Ntdsutil.

After using Ntdsutil to create the cross-reference object, the enterprise administrator must modify the cross-reference object's access control list to allow the delegated administrator to modify this cross-reference. This will allow the delegated administrator to create the application directory partition and modify the list of domain controllers that holds replicas of this application directory partition. The delegated administrator must use the names of the application directory partition and the domain controller name that were specified during the precreation process. For more information, see To prepare a cross-reference object.

For more information about application directory partitions, see Understanding application directory partitions.


Operations master roles

Active Directory supports multimaster replication of the directory data store between all domain controllers in the domain, so all domain controllers in a domain are essentially peers. However, some changes are impractical to perform in using multimaster replication, so, for each of these types of changes, one domain controller, called the operations master, accepts requests for such changes.

In every forest, there are at least five operations master roles that are assigned to one or more domain controllers. Forest-wide operations master roles must appear only once in every forest. Domain-wide operations master roles must appear once in every domain in the forest.

Note

  • The operations master roles are sometimes called flexible single master operations (FSMO) roles.

Forest-wide operations master roles

Every forest must have the following roles:

  • Schema master
  • Domain naming master

These roles must be unique in the forest. This means that throughout the entire forest there can be only one schema master and one domain naming master.

Schema master

The schema master domain controller controls all updates and modifications to the schema. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the entire forest.

Domain naming master

The domain controller holding the domain naming master role controls the addition or removal of domains in the forest. There can be only one domain naming master in the entire forest.

Note

  • Unlike a domain naming master in a forest set to the Windows 2000 functional level, a domain naming master in a forest set to the Windows Server 2003 functional level is not required to be enabled as a global catalog.

Domain-wide operations master roles

Every domain in the forest must have the following roles:

  • Relative ID (RID) master
  • Primary domain controller (PDC) emulator master
  • Infrastructure master

These roles must be unique in each domain. This means that each domain in the forest can have only one RID master, PDC emulator master, and infrastructure master.

RID master

The RID master allocates sequences of relative IDs (RIDs) to each of the various domain controllers in its domain. At any time, there can be only one domain controller acting as the RID master in each domain in the forest.

Whenever a domain controller creates a user, group, or computer object, it assigns the object a unique security ID (SID). The SID consists of a domain SID, which is the same for all SIDs created in the domain, and a RID, which is unique for each SID created in the domain.

To move an object between domains (using Movetree.exe), you must initiate the move on the domain controller acting as the RID master of the domain that currently contains the object.

PDC emulator master

If the domain contains computers operating without Windows 2000 or XOX client software or if it contains Windows NT backup domain controllers (BDCs), the PDC emulator master acts as a Windows NT primary domain controller. It processes password changes from clients and replicates updates to the BDCs. At any time, there can be only one domain controller acting as the PDC emulator master in each domain in the forest.

By default, the PDC emulator master is also responsible for synchronizing the time on all domain controllers throughout the domain. The PDC emulator of a domain gets its clock set to the clock on an arbitrary domain controller in the parent domain. The PDC emulator in the parent domain should be configured to synchronize with an external time source. You can synchronize the time on the PDC emulator with an external server by executing the "net time" command with the following syntax:

net time \\ServerName /setsntp:TimeSource

The end result is that the time of all computers running Windows Server 2003 or Windows 2000 in the entire forest are within seconds of each other.

The PDC emulator receives preferential replication of password changes performed by other domain controllers in the domain. If a password was recently changed, that change takes time to replicate to every domain controller in the domain. If a logon authentication fails at another domain controller due to a bad password, that domain controller will forward the authentication request to the PDC emulator before rejecting the log on attempt.

The domain controller configured with the PDC emulator role supports two authentication protocols:

  • the Kerberos V5 protocol
  • the NTLM protocol

Infrastructure master

At any time, there can be only one domain controller acting as the infrastructure master in each domain. The infrastructure master is responsible for updating references from objects in its domain to objects in other domains. The infrastructure master compares its data with that of a global catalog. Global catalogs receive regular updates for objects in all domains through replication, so the global catalog data will always be up to date. If the infrastructure master finds data that is out of date, it requests the updated data from a global catalog. The infrastructure master then replicates that updated data to the other domain controllers in the domain.

Important

  • Unless there is only one domain controller in the domain, the infrastructure master role should not be assigned to the domain controller that is hosting the global catalog. If the infrastructure master and global catalog are on the same domain controller, the infrastructure master will not function. The infrastructure master will never find data that is out of date, so it will never replicate any changes to the other domain controllers in the domain.

    • In the case where all of the domain controllers in a domain are also hosting the global catalog, all of the domain controllers will have the current data and it does not matter which domain controller holds the infrastructure master role.

The infrastructure master is also responsible for updating the group-to-user references whenever the members of groups are renamed or changed. When you rename or move a member of a group (and that member resides in a different domain from the group), the group may temporarily appear not to contain that member. The infrastructure master of the group's domain is responsible for updating the group so it knows the new name or location of the member. This prevents the loss of group memberships associated with a user account when the user account is renamed or moved. The infrastructure master distributes the update via multimaster replication.

There is no compromise to security during the time between the member rename and the group update. Only an administrator looking at that particular group membership would notice the temporary inconsistency.

For information about transferring operations master roles, see Transferring operations master roles. For information about what to do when an operations master fails, see Responding to operations master failures.


Transferring operations master roles

Transferring an operations master role means moving it from one domain controller to another with the cooperation of the original role holder. Depending upon the operations master role to be transferred, you perform the role transfer using one of the three Active Directory consoles in Microsoft Management Console (MMC).

Role | Console in MMC
Schema master | Active Directory Schema
Domain naming master | Active Directory Domains and Trusts
RID master | Active Directory Users and Computers
PDC emulator master | Active Directory Users and Computers
Infrastructure master | Active Directory Users and Computers

For general information about operations master roles, see Operations master roles.

Note

  • The operations master roles are sometimes called flexible single master operations (FSMO) roles.

For procedures describing the transfer of operations master roles, see:

  • Transfer the schema master role
  • Transfer the domain naming master role
  • Transfer the RID master role
  • Transfer the PDC emulator role
  • Transfer the infrastructure master role


Responding to operations master failures

Some of the operations master roles are crucial to the operation of your network. Others can be unavailable for quite some time before their absence becomes a problem. Generally, you will notice that a single master operations role holder is unavailable when you try to perform some function controlled by the particular operations master.

If an operations master is not available due to computer failure or network problems, you can seize the operations master role. This is also referred to as forcing the transfer of the operations master role. Do not seize the operations master role if you can transfer it instead. For more information, see Transferring operations master roles.

Note

  • The operations master roles are sometimes called flexible single master operations (FSMO) roles.

Before forcing the transfer, first determine the cause and expected duration of the computer or network failure. If the cause is a networking problem or a server failure that will be resolved soon, wait for the role holder to become available again. If the domain controller that currently holds the role has failed, you must determine if it can be recovered and brought back online.

In general, seizing an operations master role is a drastic step that should be considered only if the current operations master will never be available again. The decision depends upon the role and how long the particular role holder will be unavailable. The impact of various role holder failures is discussed in the following topics.

Schema master failure

Temporary loss of the schema master is not visible to network users. It will not be visible to network administrators either, unless they are trying to modify the schema or install an application that modifies the schema during installation.

If the schema master will be unavailable for an unacceptable length of time, you can seize the role to the standby operations master. However, seizing this role is a drastic step that you should take only when the failure of the schema master is permanent.

Important

  • A domain controller whose schema master role has been seized must never be brought back online.

For procedures on how to seize the schema master role, see To seize the schema master role.

Domain naming master failure

Temporary loss of the domain naming master is not visible to network users. It will not be visible to network administrators either, unless they are trying to add a domain to the forest or remove a domain from the forest.

If the domain naming master will be unavailable for an unacceptable length of time, you can seize the role to the standby operations master. However, seizing this role is a drastic step that you should take only when the failure of the domain naming master is permanent.

Important

  • A domain controller whose domain naming master role has been seized must never be brought back online.

For procedures on how to seize the domain naming master role, see To seize the domain naming master role.

RID master failure

Temporary loss of the RID master is not visible to network users. It will not be visible to network administrators either, unless they are creating objects and the domain in which they are creating the objects runs out of relative IDs (RIDs).

If the RID master will be unavailable for an unacceptable length of time, you can seize the role to the operations master. However, seizing this role is a drastic step that you should take only when the failure of the RID master is permanent.

Important

  • A domain controller whose RID master role has been seized must never be brought back online.

For procedures on how to seize the RID master role, see To seize the RID master role.

PDC emulator master failure

The loss of the primary domain controller (PDC) emulator master affects network users. Therefore, when the PDC emulator master is not available, you may need to immediately seize the role.

If the current PDC emulator master will be unavailable for an unacceptable length of time and its domain has clients without Windows 2000 client software, or if it contains Windows NT backup domain controllers, seize the PDC emulator master role to the standby operations master. When the original PDC emulator master is returned to service, you can return the role to the original domain controller.

For procedures on how to seize the PDC emulator role, see To seize the PDC emulator role.

Infrastructure master failure

Temporary loss of the infrastructure master is not visible to network users. It will not be visible to network administrators either, unless they have recently moved or renamed a large number of accounts.

If the infrastructure master will be unavailable for an unacceptable length of time, you can seize the role to a domain controller that is not a global catalog but is well connected to a global catalog (from any domain), ideally in the same site as the current global catalog. When the original infrastructure master is returned to service, you can transfer the role back to the original domain controller.

For procedures on how to seize the infrastructure master role, see To seize the infrastructure master role.

For general information about operations masters, see Operations master roles.


Understanding groups

This section covers:

  • Groups
  • Group scope
  • Group types
  • Default groups
  • Nesting groups
  • Special identities
  • Where groups can be created


Groups

A group is a collection of user and computer accounts, contacts and other groups that can be managed as a single unit. Users and computers that belong to a particular group are referred to as group members.

Using groups can simplify administration by assigning a common set of permissions and rights to many accounts at once, rather than assigning permissions and rights to each account individually. For an overview of permissions and rights, see Access control overview.

Groups can be either directory-based or local to a particular computer. Groups in Active Directory are directory objects that reside within a domain and organizational unit container objects. Active Directory provides a set of default groups upon installation, and also allows the option to create groups. For more information, see Default groups.

Local groups, which exist on local computers and not in Active Directory, are discussed in Default local groups.

Groups in Active Directory allow you to:

  • Simplify administration by assigning permissions on a shared resource to a group, rather than to individual users. This assigns the same access on the resource to all members of that group. For information, see Assign permissions to security groups on resources.
  • Delegate administration by assigning user rights once to a group through Group Policy, and then adding necessary members to the group that you want to have the same rights as the group. For information, see Assign user rights to security groups in Active Directory.
  • Create e-mail distribution lists. For information, see Group types.

Groups are characterized by their scope and their type. The scope of a group determines the extent to which the group is applied within a domain or forest. For information about group scope, see Group scope. The group type determines whether a group can be used to assign permissions from a shared resource (for security groups) or if a group can be used for e-mail distribution lists only (for distribution groups). For information about security groups and distribution groups, see Group types.

There are also groups for which you cannot modify or view the memberships. These groups are referred to as special identities and are used to represent different users at different times, depending on the circumstances. For example, the Everyone group represents all current network users, including guests and users from other domains. For more information, see Special identities.


Group scope

Groups, whether a security group or a distribution group, are characterized by a scope that identifies the extent to which the group is applied in the domain tree or forest. There are three group scopes: universal, global, and domain local.

  • Members of universal groups can include other groups and accounts from any domain in the domain tree or forest and can be assigned permissions in any domain in the domain tree or forest.
  • Members of global groups can include other groups and accounts only from the domain in which the group is defined and can be assigned permissions in any domain in the forest.
  • Members of domain local groups can include other groups and accounts from Windows Server 2003, Windows 2000, or Windows NT domains and can be assigned permissions only within a domain.

The following table summarizes the behaviors of the different group scopes.

Universal scope | Global scope | Domain local scope
When the domain functional level is set to Windows 2000 native or Windows Server 2003, members of universal groups can include accounts, global groups, and universal groups from any domain. | When the domain functional level is set to Windows 2000 native or Windows Server 2003, members of global groups can include accounts and global groups from the same domain. | When the domain functional level is set to Windows 2000 native or Windows Server 2003, members of domain local scope can include accounts, global groups, and universal groups from any domain, as well as domain local groups from the same domain.
When the domain functional level is set to Windows 2000 mixed, security groups with universal scope cannot be created. | When the domain functional level is set to Windows 2000 mixed, members of global groups can include accounts from the same domain. | When the domain functional level is set to Windows 2000 native or Windows Server 2003, members of domain local groups can include accounts and global groups from any domain.
When the domain functional level is set to Windows 2000 native or Windows Server 2003, groups can be added to other groups and assigned permissions in any domain. | Groups can be added to other groups and assigned permissions in any domain. | Groups can be added to other domain local groups and assigned permissions only in the same domain.
Groups can be converted to domain local scope. Groups can be converted to global scope, as long as no other universal groups exists as members. | Groups can be converted to universal scope, as long as the group is not a member of any other group with global scope. | Groups can be converted to universal scope, as long as the group does not have as its member another group with domain local scope.

When to use groups with domain local scope

Groups with domain local scope help you define and manage access to resources within a single domain. These groups can have as their members:

  • Groups with global scope
  • Groups with universal scope
  • Accounts
  • Other groups with domain local scope
  • A mixture of any of the above

For example, to give five users access to a particular printer, you could add all five user accounts in the printer permissions list. If, however, you later want to give the five users access to a new printer, you would again have to specify all five accounts in the permissions list for the new printer.

With a little planning, you can simplify this routine administrative task by creating a group with domain local scope and assigning it permission to access the printer. Put the five user accounts in a group with global scope and add this group to the group having domain local scope. When you want to give the five users access to a new printer, assign the group with domain local scope permission to access the new printer. All members of the group with global scope automatically receive access to the new printer.

When to use groups with global scope

Use groups with global scope to manage directory objects that require daily maintenance, such as user and computer accounts. Because groups with global scope are not replicated outside of their own domain, accounts in a group having global scope can be changed frequently without generating replication traffic to the global catalog. For more information about groups and replication, see How replication works.

Although rights and permissions assignments are valid only within the domain in which they are assigned, by applying groups with global scope uniformly across the appropriate domains, you can consolidate references to accounts with similar purposes. This will simplify and rationalize group management across domains. For example, in a network with two domains, Europe and UnitedStates, if there is a group with global scope called GLAccounting in the UnitedStates domain, there should also be a group called GLAccounting in the Europe domain (unless the accounting function does not exist in the Europe domain).

It is strongly recommended that you use global groups or universal groups instead of domain local groups when specifying permissions on domain directory objects replicated to the global catalog. For more information, see Global catalog replication.

When to use groups with universal scope

Use groups with universal scope to consolidate groups that span domains. To do this, add the accounts to groups with global scope and nest these groups within groups having universal scope. Using this strategy, any membership changes in the groups having global scope do not affect the groups with universal scope.

For example, in a network with two domains, Europe and UnitedStates, and a group having global scope called GLAccounting in each domain, create a group with universal scope called UAccounting to have as its members the two GLAccounting groups, UnitedStates\GLAccounting and Europe\GLAccounting. The UAccounting group can then be used anywhere in the enterprise. Any changes in the membership of the individual GLAccounting groups will not cause replication of the UAccounting group.

The membership of a group with universal scope should not change frequently, since any changes to these group memberships cause the entire membership of the group to be replicated to every global catalog in the forest. For more information about universal groups and replication, see Global catalog and replication.

Changing group scope

When creating a new group, by default, the new group is configured as a security group with global scope regardless of the current domain functional level. Although changing a group scope is not allowed in domains with a domain functional level set to Windows 2000 mixed, the following conversions are allowed in domains with the domain functional level set to Windows 2000 native or Windows Server 2003:

  • Global to universal. This is only allowed if the group you want to change is not a member of another global scope group.
  • Domain local to universal. This is only allowed if the group you want to change does not have another domain local group as a member.
  • Universal to global. This is only allowed if the group you want to change does not have another universal group as a member.
  • Universal to domain local. No restrictions for this operation.

For more information, see To change group scope.

Groups on client computers and stand-alone servers

Some group features, such as universal groups, group nesting, and the distinction between security groups and distribution groups, are available only on Active Directory domain controllers and member servers. Group accounts on Windows 2000 Professional, XOX, Windows 2000 Server, and stand-alone servers running Windows Server 2003 work the same way as in Windows NT 4.0:

  • Only local groups can be created locally on the computer.
  • A local group created on one of these computers can be assigned permissions only on that one computer.

For more information, see Default local groups.


Group types

Groups are used to collect user accounts, computer accounts, and other group accounts into manageable units. Working with groups instead of with individual users helps simplify network maintenance and administration.

There are two types of groups in Active Directory: distribution groups and security groups. You can use distribution groups to create e-mail distribution lists and security groups to assign permissions to shared resources.

Distributions groups

Distribution groups can be used only with e-mail applications (such as Exchange) to send e-mail to collections of users. Distribution groups are not security-enabled, which means that they cannot be listed in discretionary access control lists (DACLs). If you need a group for controlling access to shared resources, create a security group.

Security groups

Used with care, security groups provide an efficient way to assign access to resources on your network. Using security groups, you can:

  • Assign user rights to security groups in Active Directory

    User rights are assigned to security groups to determine what members of that group can do within the scope of a domain (or forest). User rights are automatically assigned to some security groups at the time Active Directory is installed to help administrators define a person's administrative role in the domain. For example, a user who is added to the Backup Operators group in Active Directory has the ability to backup and restore files and directories located on each domain controller in the domain.

    This is possible because by default, the user rights Backup files and directories and Restore files and directories are automatically assigned to the Backup Operators group. Therefore, members of this group inherit the user rights assigned to that group. For more information about user rights, see User rights. For more information about the user rights assigned to security groups, see Default groups.

    • You can assign user rights to security groups, using Group Policy, to help delegate specific tasks. You should always use discretion when assigning delegated tasks because an untrained user assigned too many rights on a security group can potentially cause significant harm to your network. For more information, see Delegating administration. For more information about assigning user rights to groups, see To assign user rights to a group in Active Directory.

  • Assign permissions to security groups on resources

    Permissions should not be confused with user rights. Permissions are assigned to the security group on the shared resource. Permissions determine who can access the resource and the level of access, such as Full Control. Some permissions set on domain objects are automatically assigned to allow various levels of access to default security groups such as the Account Operators group or the Domain Admins group. For more information about permissions, see Access control in Active Directory.

    Security groups are listed in DACLs that define permissions on resources and objects. When assigning permissions for resources (file shares, printers, and so on), administrators should assign those permissions to a security group rather than to individual users. The permissions are assigned once to the group, instead of several times to each individual user. Each account added to a group receives the rights assigned to that group in Active Directory and the permissions defined for that group at the resource.

Like distribution groups, security groups can also be used as an e-mail entity. Sending an e-mail message to the group sends the message to all the members of the group.

Converting between security and distribution groups

A group can be converted from a security group to a distribution group, and vice versa, at any time, but only if the domain functional level is set to Windows 2000 native or higher. No groups can be converted while the domain functional level is set to Windows 2000 mixed.

For specific procedural information, see To convert a group to another group type. For information about domain functionality, see Understanding domain and forest functionality.

Note

  • Although a contact can be added to a security group as well as to a distribution group, contacts cannot be assigned rights and permissions. Contacts in a group can be sent e-mail.


Default groups

Default groups, such as the Domain Admins group, are security groups that are created automatically when you create an Active Directory domain. You can use these predefined groups to help you control access to shared resources and delegate specific domain-wide administrative roles. For information about default groups stored on local computers, see Default local groups.

Many default groups are automatically assigned a set of user rights that authorize members of the group to perform specific actions in a domain, such as logging on to a local system or backing up files and folders. For example, a member of the Backup Operators group has the right to perform backup operations for all domain controllers in the domain.

When you add a user to a group, the user receives all the user rights assigned to the group and all the permissions assigned to the group on any shared resources. For more information about user rights, see Assign user rights to security groups in Active Directory. For more information about permissions, see Assign permissions to security groups on resources.

You can manage groups by using Active Directory Users and Computers. Default groups are located in the Builtin container and the Users container. The Builtin container contains groups that are defined with domain local scope. The Users container contains groups that are defined with global scope and groups that are defined with domain local scope. You can move groups located in these containers to other groups or organizational units within the domain, but you cannot move them to other domains.

As a security best practice, it is recommended that members of default groups with broad administrative access use Run as to perform administrative tasks. For more information, see Using Run as. For information about security best practices, see Best practices. For information about additional security measures that can be used to protect Active Directory, see Securing Active Directory.

Note

  • To learn what group you need to be a member of to perform a particular procedure, many procedural topics under How To in Help and Support Center provide a note that identifies this information.

Groups in the Builtin container

The following table provides descriptions of the default groups located in the Builtin container and lists the assigned user rights for each group. For complete descriptions of the user rights listed in the table, see User rights assignment. For information about editing these rights, see To edit a security setting on a Group Policy object.

Group | Description | Default user rights
Account Operators | Members of this group can create, modify, and delete accounts for users, groups, and computers located in the Users or Computers containers and organizational units in the domain, except the Domain Controllers organizational unit. Members of this group do not have permission to modify the Administrators or the Domain Admins groups, nor do they have permission to modify the accounts for members of those groups. Members of this group can log on locally to domain controllers in the domain and shut them down. Because this group has significant power in the domain, add users with caution. | Allow log on locally; Shut down the system.
Administrators | Members of this group have full control of all domain controllers in the domain. By default, the Domain Admins and Enterprise Admins groups are members of the Administrators group. The Administrator account is also a default member. Because this group has full control in the domain, add users with caution. | Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force a shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects.
Backup Operators | Members of this group can back up and restore all files on domain controllers in the domain, regardless of their own individual permissions on those files. Backup Operators can also log on to domain controllers and shut them down. This group has no default members. Because this group has significant power on domain controllers, add users with caution. | Back up files and directories; Allow log on locally; Restore files and directories; Shut down the system.
Guests | By default, the Domain Guests group is a member of this group. The Guest account (which is disabled by default) is also a default member of this group. | No default user rights.
Incoming Forest Trust Builders (only appears in the forest root domain) | Members of this group can create one-way, incoming forest trusts to the forest root domain. For example, members of this group residing in Forest A can create a one-way, incoming forest trust from Forest B. This one-way, incoming forest trust allows users in Forest A to access resources located in Forest B. Members of this group are granted the permission Create Inbound Forest Trust on the forest root domain. This group has no default members. For more information about creating forest trusts, see To create a forest trust. | No default user rights.
Network Configuration Operators | Members of this group can make changes to TCP/IP settings and renew and release TCP/IP addresses on domain controllers in the domain. This group has no default members. | No default user rights.
Performance Monitor Users | Members of this group can monitor performance counters on domain controllers in the domain, locally and from remote clients without being a member of the Administrators or Performance Log Users groups. | No default user rights.
Performance Log Users | Members of this group can manage performance counters, logs and alerts on domain controllers in the domain, locally and from remote clients without being a member of the Administrators group. | No default user rights.
Pre-Windows 2000 Compatible Access | Members of this group have read access on all users and groups in the domain. This group is provided for backward compatibility for computers running Windows NT 4.0 and earlier. By default, the special identity Everyone is a member of this group. For more information about special identities, see Special identities. Add users to this group only if they are running Windows NT 4.0 or earlier. | Access this computer from the network; Bypass traverse checking.
Print Operators | Members of this group can manage, create, share, and delete printers connected to domain controllers in the domain. They can also manage Active Directory printer objects in the domain. Members of this group can log on locally to domain controllers in the domain and shut them down. This group has no default members. Because members of this group can load and unload device drivers on all domain controllers in the domain, add users with caution. | Allow log on locally; Shut down the system.
Remote Desktop Users | Members of this group can remotely log on to domain controllers in the domain. This group has no default members. | No default user rights.
Replicator | This group supports directory replication functions and is used by the File Replication service on domain controllers in the domain. This group has no default members. Do not add users to this group. | No default user rights.
Server Operators | On domain controllers, members of this group can log on interactively, create and delete shared resources, start and stop some services, back up and restore files, format the hard disk, and shut down the computer. This group has no default members. Because this group has significant power on domain controllers, add users with caution. | Back up files and directories; Change the system time; Force shutdown from a remote system; Allow log on locally; Restore files and directories; Shut down the system.
Users | Members of this group can perform most common tasks, such as running applications, using local and network printers, and locking the server. By default, the Domain Users group, Authenticated Users, and Interactive are members of this group. Therefore, any user account created in the domain becomes a member of this group. | No default user rights.

Groups in the Users container

The following table provides a description of the default groups located in the Users container and lists the assigned user rights for each group. For complete descriptions of the user rights listed in the table, see User rights assignment. For information about editing these rights, see To edit a security setting on a Group Policy object.

Group | Description | Default user rights
Cert Publishers | Members of this group are permitted to publish certificates for users and computers. This group has no default members. | No default user rights.
DnsAdmins (installed with DNS) | Members of this group have administrative access to the DNS Server service. This group has no default members. | No default user rights.
DnsUpdateProxy (installed with DNS) | Members of this group are DNS clients that can perform dynamic updates on behalf of other clients, such as DHCP servers. This group has no default members. | No default user rights.
Domain Admins | Members of this group have full control of the domain. By default, this group is a member of the Administrators group on all domain controllers, all domain workstations, and all domain member servers at the time they are joined to the domain. By default, the Administrator account is a member of this group. Because the group has full control in the domain, add users with caution. | Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force a shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects.
Domain Computers | This group contains all workstations and servers joined to the domain. By default, any computer account created becomes a member of this group automatically. | No default user rights.
Domain Controllers | This group contains all domain controllers in the domain. | No default user rights.
Domain Guests | This group contains all domain guests. | No default user rights.
Domain Users | This group contains all domain users. By default, any user account created in the domain becomes a member of this group automatically. This group can be used to represent all users in the domain. For example, if you want all domain users to have access to a printer, you can assign permissions for the printer to this group (or add the Domain Users group to a local group, on the print server, that has permissions for the printer). | No default user rights.
Enterprise Admins (only appears in the forest root domain) | Members of this group have full control of all domains in the forest. By default, this group is a member of the Administrators group on all domain controllers in the forest. By default, the Administrator account is a member of this group. Because this group has full control of the forest, add users with caution. | Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects.
Group Policy Creator Owners | Members of this group can modify Group Policy in the domain. By default, the Administrator account is a member of this group. Because this group has significant power in the domain, add users with caution. | No default user rights.
IIS_WPG (installed with IIS) | The IIS_WPG group is the Internet Information Services (IIS) 6.0 worker process group. Within the functioning of IIS 6.0 are worker processes that serve specific namespaces. For example, www.microsoft.com is a namespace served by one worker process, which can run under an identity added to the IIS_WPG group, such as MicrosoftAccount. This group has no default members. | No default user rights.
RAS and IAS Servers | Servers in this group are permitted access to the remote access properties of users. | No default user rights.
Schema Admins (only appears in the forest root domain) | Members of this group can modify the Active Directory schema. By default, the Administrator account is a member of this group. Because this group has significant power in the forest, add users with caution. | No default user rights.


Nesting groups

Using nesting, you can add a group as a member of another group. You nest groups to consolidate member accounts and reduce replication traffic.

Nesting options depend on whether the domain functionality of your Windows Server 2003 domain is set to Windows 2000 native or Windows 2000 mixed.

Groups in domains set to the Windows 2000 native functional level or distribution groups in domains set to the Windows 2000 mixed functional level can have the following members:

  • Groups with universal scope can have the following members: accounts, computer accounts, other groups with universal scope, and groups with global scope from any domain.
  • Groups with global scope can have the following members: accounts from the same domain and other groups with global scope from the same domain.
  • Groups with domain local scope can have the following members: accounts, groups with universal scope, and groups with global scope, all from any domain. This group can also have as members other groups with domain local scope from within the same domain.

Security groups in domains set to the Windows 2000 mixed functional level are restricted to the following types of membership:

  • Groups with global scope can have as their members only accounts.
  • Groups with domain local scope can have as their members other groups with global scope and accounts.

Security groups with universal scope cannot be created in domains with the domain functional level set to Windows 2000 mixed because universal scope is supported only in domains where the domain functional level is set to Windows 2000 native or Windows Server 2003.

For more information about domain functionality, see Understanding domain and forest functionality.


Special identities

In addition to the groups in the Users and Builtin containers, servers running Windows Server 2003 include several special identities. For convenience, these identities are generally referred to as groups. These special groups do not have specific memberships that can be modified, but they can represent different users at different times, depending on the circumstances. The special groups are:

  • Anonymous Logon

    Represents users and services that access a computer and its resources through the network without using an account name, password, or domain name. On computers running Windows NT and earlier, the Anonymous Logon group is a default member of the Everyone group. On computers running a member of the Windows Server 2003 family, the Anonymous Logon group is not a member of the Everyone group by default.

  • Everyone

    Represents all current network users, including guests and users from other domains. Whenever a user logs on to the network, the user is automatically added to the Everyone group.

  • Network

    Represents users currently accessing a given resource over the network (as opposed to users who access a resource by logging on locally at the computer where the resource is located). Whenever a user accesses a given resource over the network, the user is automatically added to the Network group.

  • Interactive

    Represents all users currently logged on to a particular computer and accessing a given resource located on that computer (as opposed to users who access the resource over the network). Whenever a user accesses a given resource on the computer to which they are currently logged on, the user is automatically added to the Interactive group.

Although the special identities can be assigned rights and permissions to resources, the memberships cannot be modified or viewed. Group scopes do not apply to special identities. Users are automatically assigned to these special identities whenever they log on or access a particular resource.

For general information about groups, see Groups.


Where groups can be created

In Active Directory, groups are created in domains. You use Active Directory Users and Computers to create groups. With the necessary permissions, groups can be created in the root domain of the forest, in any other domain in the forest, or in an organizational unit.

Besides the domain in which it is created, a group is also characterized by its scope. The scope of a group determines:

  • The domain from which members can be added
  • The domain in which the rights and permissions assigned to the group are valid

For more information about group scopes, see Group scope.

Choose the particular domain or organizational unit where you create a group based on the administration required for the group. For example, if your directory has multiple organizational units, each of which has a different administrator, you may want to create groups with global scope within those organizational units so those administrators can manage group membership for users in their respective organizational units. If groups are required for access control outside the organizational unit, the groups within the organizational unit can be nested into groups with universal scope (or other groups with global scope) that can be used elsewhere in the forest.

If the domain functional level is set to Windows 2000 native or higher, the domain contains a hierarchy of organizational units and administration is delegated to administrators at each organizational unit, it may be more efficient to nest groups with global scope. For example, if the organizational unit OU1 contained organizational units OU2 and OU3, a group with global scope in OU1 could have as its members groups with global scope in OU2 and OU3. In OU1, the administrator could add or remove group members from OU1, and the administrators of OU2 and OU3 could add or remove group members for accounts from their own organizational units without having administrative rights for the group with global scope in OU1.

Note

  • Groups can be moved within a domain. However, only groups with universal scope can be moved from one domain to another. The rights and permissions assigned to a group with universal scope are lost when the group is moved to another domain and new assignments must be made.
For information about the tools used to move groups between domains, see Windows Deployment and Resource Kits.


Understanding trusts

This section covers:

  • Trusts
  • Trust types
  • Trust direction
  • Trust transitivity
  • When to create an external trust
  • When to create a shortcut trust
  • When to create a realm trust
  • When to create a forest trust
  • Forest trusts
  • Accessing resources across domains
  • Accessing resources across forests
  • Routing name suffixes across forests


Trusts

A trust is a relationship established between domains that enables users in one domain to be authenticated by a domain controller in the other domain. Trust relationships in Windows NT are different than in Windows 2000 and Windows Server 2003 operating systems.

Trusts in Windows NT

In Windows NT 4.0 and earlier, trusts are limited to two domains and the trust relationship is one-way and nontransitive. In the following figure, the nontransitive, one-way trust is shown by the straight arrow pointing to the trusted domain.

Simple domain trust

Trusts in Windows Server 2003 and Windows 2000 server operating systems

All trusts in a Windows 2000 and Windows Server 2003 forest are transitive, two-way trusts. Therefore, both domains in a trust relationship are trusted. As shown in the following figure, this means that if Domain A trusts Domain B and Domain B trusts Domain C, then users from Domain C can access resources in Domain A (when assigned the proper permissions). Only members of the Domain Admins group can manage trust relationships.

Transitive trusts in a domain tree

Trust protocols

A domain controller running Windows Server 2003 authenticates users and applications using one of two protocols: Kerberos V5 or NTLM. The Kerberos V5 protocol is the default protocol for computers running Windows 2000, XOX, or Windows Server 2003. If any computer involved in a transaction does not support Kerberos V5, the NTLM protocol will be used.

With the Kerberos V5 protocol, the client requests a ticket from a domain controller in its account domain to the server in the trusting domain. This ticket is issued by an intermediary trusted by the client and the server. The client presents this trusted ticket to the server in the trusting domain for authentication. For more information, see Kerberos V5 authentication.

When a client tries to access resources on a server in another domain using NTLM authentication, the server containing the resource must contact a domain controller in the client account domain to verify the account credentials.

Trusted domain objects

Trusted domain objects (TDOs) are objects that represent each trust relationship within a particular domain. Each time a trust is established a unique TDO is created and stored (in the System container) in its domain. Attributes such as a trust transitivity, type, and the reciprocal domain names are represented in a TDO.

Forest trust TDOs store additional attributes to identify all of the trusted namespaces from its partner forest. These attributes include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces.

For more information about domain trusts, see "Domain Trust" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/) For more information about trust relationships, see "Designing an Authorization Strategy" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Trust types

Communication between domains occurs through trusts. Trusts are authentication pipelines that must be present in order for users in one domain to access resources in another domain. Two default trusts are created when using the Active Directory Installation Wizard. There are four other types of trusts that can be created using the New Trust Wizard or the Netdom command-line tool.

Default trusts

By default, two-way, transitive trusts are automatically created when a new domain is added to a domain tree or forest root domain using the Active Directory Installation Wizard. The two default trust types are defined in the following table.

Trust type | Transitivity | Direction | Description
Parent and child | Transitive | Two-way | By default, when a new child domain is added to an existing domain tree, a new parent and child trust is established. Authentication requests made from subordinate domains flow upward through their parent to the trusting domain. For information about creating a new child domain, see To create a new child domain.
Tree-root | Transitive | Two-way | By default, when a new domain tree is created in an existing forest, a new tree-root trust is established. For information about creating a new domain tree, see To create a new domain tree.

Other trusts

Four other types of trusts can be created using the New Trust Wizard or the Netdom command-line tool: external, realm, forest, and shortcut trusts. These trusts are defined in the following table.

Trust type | Transitivity | Direction | Description
External | Nontransitive | One-way or two-way | Use external trusts to provide access to resources located on a Windows NT 4.0 domain or a domain located in a separate forest that is not joined by a forest trust. For more information, see When to create an external trust.
Realm | Transitive or nontransitive | One-way or two-way | Use realm trusts to form a trust relationship between a non-Windows Kerberos realm and a Windows Server 2003 domain. For more information, see When to create a realm trust.
Forest | Transitive | One-way or two-way | Use forest trusts to share resources between forests. If a forest trust is a two-way trust, authentication requests made in either forest can reach the other forest. For more information, see When to create a forest trust.
Shortcut | Transitive | One-way or two-way | Use shortcut trusts to improve user logon times between two domains within a Windows Server 2003 forest. This is useful when two domains are separated by two domain trees. For more information, see When to create a shortcut trust.

When creating external, shortcut, realm, or forest trusts, you have the option to create each side of the trust separately or both sides of a trust simultaneously.

If you choose to create each side of the trust separately, then you will need to run the New Trust Wizard twice—once for each domain. When creating trusts using the method, you will need to supply the same trust password for each domain. As a security best practice, all trust passwords should be strong passwords. For more information, see Strong passwords.

If you choose to create both sides of the trust simultaneously, you will need to run the New Trust Wizard once. When you choose this option, a strong trust password is automatically generated for you.

You will need the appropriate administrative credentials for each domain between which you will be creating a trust.

Netdom.exe can also be used to create trusts. For more information about Netdom, see Active Directory support tools.

For more information about trusts, see Trust transitivity and Trust direction.


Trust direction

The trust type and its assigned direction will impact the trust path used for authentication. A trust path is a series of trust relationships that authentication requests must follow between domains. Before a user can access a resource in another domain, the security system on domain controllers running Windows Server 2003 must determine whether the trusting domain (the domain containing the resource the user is trying to access) has a trust relationship with the trusted domain (the user's logon domain). To determine this, the security system computes the trust path between a domain controller in the trusting domain and a domain controller in the trusted domain. In the following figure, trust paths are indicated by arrows showing the direction of the trust:

Direction of trust path

All domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain.

One-way trust

A one-way trust is a unidirectional authentication path created between two domains. This means that in a one-way trust between Domain A and Domain B, users in Domain A can access resources in Domain B. However, users in Domain B cannot access resources in Domain A. Some one-way trusts can be a nontransitive trust or a transitive trust depending on the type of trust being created. For more information about trust types, see Trust types.

Two-way trust

All domain trusts in a Windows Server 2003 forest are two-way, transitive trusts. When a new child domain is created, a two-way, transitive trust is automatically created between the new child domain and the parent domain. In a two-way trust, Domain A trusts Domain B and Domain B trusts Domain A. This means that authentication requests can be passed between the two domains in both directions. Some two-way relationships can be nontransitive or transitive depending on the type of trust being created. For more information, see Trust types.

A Windows Server 2003 domain can establish a one-way or two-way trust with:

  • Windows Server 2003 domains in the same forest
  • Windows Server 2003 domains in a different forest
  • Windows NT 4.0 domains
  • Kerberos V5 realms

For more information Kerberos V5, see Kerberos V5 authentication.


Trust transitivity

Transitivity determines whether a trust can be extended outside of the two domains with which it was formed. A transitive trust can be used to extend trust relationships with other domains and a nontransitive trust can be used to deny trust relationships with other domains.

Transitive trusts

Each time you create a new domain in a forest, a two-way, transitive trust relationship is automatically created between the new domain and its parent domain. If child domains are added to the new domain, the trust path flows upward through the domain hierarchy extending the initial trust path created between the new domain and its parent domain.

Transitive trust relationships flow upward through a domain tree as it is formed, creating transitive trusts between all domains in the domain tree.

Authentication requests follow these trust paths, so accounts from any domain in the forest can be authenticated at any other domain in the forest. With a single logon process, accounts with the proper permissions can access resources in any domain in the forest. For more information, see Authentication.

A two-way, transitive trust path automatically connects all domains in a forest.

The diagram displays that all domains in the Domain A tree and all domains in the Domain 1 tree have transitive trust relationships by default. As a result, users in the Domain A tree can access resources in domains in the Domain 1 tree and users in the Domain 1 tree can access resources in the Domain A tree, when the proper permissions are assigned at the resource.

In addition to the default transitive trusts established in a Windows Server 2003 forest, using the New Trust Wizard, you can manually create the following transitive trusts.

  • Shortcut trust. A transitive trust between a domain in the same domain tree or forest used to shorten the trust path in a large and complex domain tree or forest.
  • Forest trust. A transitive trust between a forest root domain and a second forest root domain.
  • Realm trust. A transitive trust between an Active Directory domain and an Kerberos V5 realm. For more information about Kerberos V5 realms, see Kerberos V5 authentication.

For more information about trust types, see Trust types.

Nontransitive trust

A nontransitive trust is restricted by the two domains in the trust relationship and does not flow to any other domains in the forest. A nontransitive trust can be a two-way trust or a one-way trust.

Nontransitive trusts are one-way by default, although you can also create a two-way relationship by creating two one-way trusts. In summary, nontransitive domain trusts are the only form of trust relationship possible between:

  • A Windows Server 2003 domain and a Windows NT domain
  • A Windows Server 2003 domain in one forest and a domain in another forest (when not joined by a forest trust)

Using the New Trust Wizard, you manually create the following nontransitive trusts:

  • External trust. A nontransitive trust created between a Windows Server 2003 domain and a Windows NT domain or a Windows 2000 domain or Windows Server 2003 domain in another forest.

    When you upgrade a Windows NT domain to a Windows Server 2003 domain, all existing Windows NT trusts are preserved intact. All trust relationships between Windows Server 2003 domains and Windows NT domains are nontransitive.

  • Realm trust. A nontransitive trust between an Active Directory domain and an Kerberos V5 realm. For more information about Kerberos V5 realms, see Kerberos V5 authentication.

For more information about trust types, see Trust types.


When to create an external trust

You can create an external trust to form a one-way or two-way, nontransitive trust with domains outside of your forest. External trusts are sometimes necessary when users need access to resources located in a Windows NT 4.0 domain or in a domain located within a separate forest that is not joined by a forest trust, as shown in the figure.

External trusts

When a trust is established between a domain in a particular forest and a domain outside of that forest, security principals from the external domain can access resources in the internal domain. Active Directory creates a foreign security principal object in the internal domain to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups in the internal domain. Domain local groups can have members from domains outside of the forest.

Directory objects for foreign security principals are created by Active Directory and should not be manually modified. You can view foreign security principal objects from Active Directory Users and Computers by enabling advanced features. For information about enabling advanced features, see To view advanced features.

In domains with the functional level set to Windows 2000 mixed, it is recommended that you delete external trusts from a domain controller running Windows Server 2003. External trusts to Windows NT 4.0 or 3.51 domains can be deleted by authorized administrators on the domain controllers running Windows NT 4.0 or 3.51. However, only the trusted side of the relationship can be deleted on the domain controllers running Windows NT 4.0 or 3.51. The trusting side of the relationship (created in the Windows Server 2003 domain) is not deleted, and although it will not be operational, the trust will continue to display in Active Directory Domains and Trusts. To remove the trust completely, you will need to delete the trust from a domain controller running Windows Server 2003 in the trusting domain. If an external trust is inadvertently deleted from a domain controller running Windows NT 4.0 or 3.51, you will need to recreate the trust from any domain controller running Windows Server 2003 in the trusting domain.

For more information about how to create an external trust, see To create an external trust.

Securing external trusts

To improve the security of Active Directory forests, domain controllers running Windows Server 2003 and Windows 2000 Service Pack 4 (or higher) enable security identifier (SID) filtering on all new outgoing external trusts by default.

By applying SID filtering to outgoing external trusts, you prevent malicious users who have domain administrator level access in the trusted domain from granting, to themselves or other user accounts in their domain, elevated user rights to the trusting domain.

When a malicious user can grant unauthorized user rights to another user it is known as an elevation of privilege attack. For more information about SID Filtering and how to further mitigate an elevation of privilege attack, see Using Security Identifier (SID) Filtering to Prevent Elevation of Privilege Attacks at the Microsoft Web site. (http://www.microsoft.com/)

How SID Filtering works

When security principals are created in a domain, the domain SID is included in the security principal's SID to identify the domain in which it was created. The domain SID is an important characteristic of a security principal because the Windows security subsystem uses it to verify the security principal's authenticity.

In a similar fashion, outgoing external trusts created from the trusting domain use SID filtering to verify that incoming authentication requests made from security principals in the trusted domain only contain SIDs of security principals in the trusted domain. This is done by comparing the SIDs of the incoming security principal to the domain SID of the trusted domain. If any of the security principal SIDs include a domain SID other than the one from the trusted domain, the trust removes the offending SID.

SID filtering ensures that any misuse of the SIDHistory attribute on security principals (including inetOrgPerson) in the trusted forest cannot pose a threat to the integrity of the trusting forest.

The SIDHistory attribute can be useful to domain administrators when they migrate user and group accounts from one domain to another. Domain administrators can add SIDs from an old user or group account to the SIDHistory attribute of the new, migrated account. By doing this, domain administrators give the new account the same level of access to resources as the old account.

If domain administrators could not use the SIDHistory attribute in this way, they would have to track down and reapply permissions for the new account on each network resource that the old account had access to.

Understanding the threat

If not for SID filtering on outgoing external trusts, a malicious user with administrative credentials residing in the trusted domain could sniff network authentication requests from the trusting domain to obtain the SID information of a user who has full access to resources in the trusting domain, such as a domain administrator.

After obtaining the domain administrators SID from the trusting domain, a malicious user with administrative credentials can add that SID to a user account's SIDHistory attribute in the trusted domain and attempt to gain full access to the trusting domain and the resources within that domain. In this scenario, a malicious user who has domain administrator credentials in the trusted domain is a threat to the entire trusting forest.

SID filtering neutralizes the threat of malicious users in the trusted domain from using the SIDHistory attribute to gain elevated privileges.

Impact of SID filtering

SID filtering on external trusts can affect your existing Active Directory infrastructure in the following two areas:

  • SID history data that contains SIDs from any domain other than the trusted domain will be removed from authentication requests made from the trusted domain. This will result in access being denied to resources that have the user's old SID.
  • Universal group access control strategy between forests will require changes.

When SID filtering is enabled, users who use SID history data for authorization to resources in the trusting domain no longer have access to those resources.

If you typically assign universal groups from a trusted forest to access control lists (ACLs) on shared resources in the trusting domain, SID filtering will have a major impact on your access control strategy.

Because universal groups must adhere to the same SID filtering guidelines as other security principal objects (that is, the universal group object SID must also contain the domain SID), you should verify that any universal groups that are assigned to shared resources in the trusting domain were created in the trusted domain.

If the universal group in the trusted forest was not created in the trusted domain, even though it may contain users from the trusted domain as members, authentication requests made from members of that universal group will be filtered and discarded.

Therefore, before assigning access to resources in the trusting domain for users in the trusted domain, you should confirm that the universal group containing the trusted domain users was created in the trusted domain.

Disabling SID Filtering

Although it is not recommended, you can disable SID filtering for an external trust by using the Netdom.exe tool. You should consider disabling SID filtering only in the following situations:

  • You have the same level of trust for all administrators who have physical access to domain controllers in the trusted domain as the administrators in the trusting domain.
  • You have a strict requirement to assign universal groups to resources in the trusting domain that were not created in the trusted domain.
  • Users have been migrated to the trusted domain with their SID histories preserved, and you want to grant them access to resources in the trusting domain based on the SIDHistory attribute.

Only domain administrators can disable SID filtering. To disable SID filtering for the trusting domain, type the following syntax at a command-prompt:

Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /usero:domainadministratorAcct /passwordo:domainadminpwd

To enable SID filtering, set the /quarantine: command-line option to Yes. For more information about Netdom.exe, see Active Directory support tools.

You can enable or disable SID filtering only from the trusting side of the trust. If the trust is a two-way trust, you can also disable SID filtering in the trusted domain by using the domain administrator's credentials for the trusted domain and reversing the TrustingDomainName and TrustedDomainName values in the command-line syntax.

Notes

  • To further secure your forest, you should consider enabling SID filtering on all existing external trusts that were created by domain controllers running Windows 2000 Service Pack 3 (or earlier). You can do this by using Netdom.exe to enable SID filtering on existing external trusts, or by recreating these external trusts from a domain controller running Windows Server 2003 or Windows 2000 Service Pack 4 (or later).
  • You cannot turn off the default behavior that enables SID filtering for newly created external trusts.
  • External trusts created from domain controllers running Windows 2000 Service Pack 3 (or earlier) do not enforce SID filtering by default.
  • Domain controllers running Windows NT Server 4.0 do not take part in the trust creation process when existing domain controllers in the same domain are running Windows 2000 or Windows Server 2003.
  • You can enable or disable SID filtering only for trusts that extend beyond forest boundaries such as external and forest trusts. For more information about SID filtering and forest trusts, see Forest trusts.


When to create a shortcut trust

Shortcut trusts are one-way or two-way, transitive trusts that can be used when administrators need to optimize the authentication process. Authentication requests must first travel a trust path between domain trees, and in a complex forest this can take time, which can be reduced with shortcut trusts. A trust path is the series of domain trust relationships that must be traversed in order to pass authentication requests between any two domains. For more information about trust paths, see Trust direction.

Shortcut trusts are necessary when many users in a domain regularly log on to other domains in a forest. For example, using the following figure as an example, you could form a shortcut trust between domain B and domain D or domain A and domain 1 and so on.

Shortcut trusts in a forest

Shortcut trusts effectively shorten the path traveled for authentication's made between domains located in two separate trees.

For more information about how to create a shortcut trust, see To create a shortcut trust.

Using one-way trusts

A one-way, shortcut trust established between two domains located in separate domain trees can reduce the time needed to fulfill authentication requests, but in only one direction. For example, when a one-way, shortcut trust is established between domain A and domain B, authentication requests made in domain A to domain B can utilize the new one-way trust path. However, authentication requests made in domain B to domain A will still need to travel the longer trust path.

Using two-way trusts

A two-way, shortcut trust established between two domains located in separate domain trees will reduce the time needed to fulfill authentication requests originating in either domain. For example, when a two-way trust is established between domain A and domain B, authentication requests made from either domain to the other can utilize the new, two-way trust path.


When to create a realm trust

A realm trust can be established between any non-Windows Kerberos V5 realm and a Windows Server 2003 domain. This trust relationship allows cross-platform interoperability with security services based on other Kerberos V5 versions such as UNIX and MIT implementations. Realm trusts can switch from nontransitive to transitive and back. Realm trusts can also be either one-way or two-way.

For more information about how to create a realm trust, see To create a realm trust.


When to create a forest trust

A forest trust can only be created between a forest root domain in one Windows Server 2003 forest and a forest root domain in another Windows Server 2003 forest. Creating a forest trust between two Windows Server 2003 forests provides a one-way or two-way, transitive trust relationship between every domain residing within each forest. Forest trusts are useful for Application Service Providers, companies undergoing mergers or acquisitions, collaborative business extranets, and companies seeking a solution for administrative autonomy.

For more information about creating forest trusts, see Checklist: Creating a forest trust.

Using one-way forest trusts

A one-way, forest trust between two forests allows members of the trusted forest to utilize resources located in the trusting forest. However, the trust operates in only one direction. For example, when a one-way, forest trust is created between forest A (the trusted forest) and forest B (the trusting forest), members of forest A can access resources located in forest B, but members of forest B cannot access resources located in forest A using the same trust.

Using two-way forest trusts

A two-way, forest trust between two forests allows members from either forest to utilize resources located in the other forest; domains in each respective forest trust domains in the other forest implicitly. For example, when a two-way, forest trust is established between forest A and forest B, members of forest A can access resources located in forest B, and members of forest B can access resources in forest A, using the same trust.


Forest trusts

In a Windows Server 2003 forest, you can link two disjoined Windows Server 2003 forests together to form a one-way or two-way, transitive trust relationships. A two-way, forest trust is used to form a transitive trust relationship between every domain in both forests.

Forest trusts can provide the following benefits:

  • Simplified management of resources across two Windows Server 2003 forests by reducing the number of external trusts necessary to share resources.
  • Complete two-way trust relationships with every domain in each forest.
  • Use of user principal name (UPN) authentication across two forests.
  • Use of both the Kerberos V5 and NTLM authentication protocols to improve the trustworthiness of authorization data transferred between forests.
  • Flexibility of administration. Administrative tasks can be unique to each forest.

Forest trusts can only be created between two forests and cannot be implicitly extended to a third forest. This means that if a forest trust is created between forest 1 and forest 2, and a forest trust is also created between forest 2 and forest 3, forest 1 will not have an implicit trust with forest 3. For more information about the requirements needed for a forest trust, see When to create a forest trust.

Notes

  • In a Windows 2000 forest, if users in one forest need to access resources in another forest, an administrator can create an external trust relationship between the two domains. External trusts can be one-way or two-way and are nontransitive, and therefore, limit the ability for trust paths to extend to other domains. For more information about external trusts, see Trust types.
  • By default, new external and forest trusts in Windows Server 2003 Active Directory enforce SID filtering. SID filtering is used to prevent attacks from malicious users who might try to grant elevated user rights to another user account. Enforcing SID filtering on forest trusts does not prevent migrations to domains within the same forest from using SID history and will not affect your universal group access control strategy. For more information about SID filtering, see Securing external trusts.

Managing a multiple forest environment

Forest trusts help you to manage a segmented Active Directory infrastructure within your organization by providing support for accessing resources and other objects across multiple forests. For more information about accessing resources across multiple forests, see Accessing resources across forests.

Because each forest is administered separately, adding additional forests to your organization increases your organization's management needs. For more information, see Creating a new forest.

Reasons to create multiple forests in your organization include:

  • To secure data within each forest. Sensitive data can be protected so that only users within that forest can access it.
  • To isolate directory replication within each forest. Schema changes, configuration changes, and the addition of new domains to a forest only have forest-wide impact within that forest, not on a trusting forest.

Delegating forest-wide administrative control

Active Directory data that is stored in the schema and configuration containers is replicated to every domain controller in the forest. Since changes to the schema and configuration containers will affect all domains in the forest, administrative control for forest-wide changes should be entrusted to highly trained or experienced administrators. All domain data contained in the forest root domain should also be regarded as highly sensitive data.

The following groups provide forest-wide administrative control in each forest:

  • Enterprise Admins
  • Domain Admins (in the forest root domain)
  • Schema Admins

Since membership in any of these groups can affect forest-wide behavior, add users with caution. As a security best practice, avoid adding users from another forest to any of these forest-wide administrative groups. For more information about these groups, see Default groups.

Synchronizing data across forests

You can synchronize global address lists (GALs) and objects across forests using Microsoft Metadirectory Services (MMS) or another supported synchronization tool. Common data types that need synchronization across forests include:

  • GALs (Exchange)
  • Public folders
  • Directory objects

Synchronizing this data across forests will help end users view address lists and other data the same way as they do when viewing this information within their own forest.

For more information about MMS, see Microsoft Metadirectory Services (http://www.microsoft.com/).


Accessing resources across domains

Since two or more Active Directory domains within the same forest are implicitly connected by two-way, transitive trusts, authentication requests made from one domain to another are successfully routed in order to provide a seamless coexistence of resources across domains. Users can only gain access to resources in other domains after first being authenticated in their own domain.

Domain controllers running Windows 2000 or Windows Server 2003 authenticate users and applications using one of two authentication protocols: Kerberos V5 or NTLM. For more information about Kerberos authentication, see Kerberos V5 authentication. For more information about NTLM authentication, see NTLM authentication. For more information about the Active Directory authentication process, see Access control in Active Directory.

Once authenticated, the user can attempt to gain access to resources from any domain in the forest using the Active Directory authorization process. For more information about the Active Directory authorization process, see Security information for Active Directory.

To access a shared resource in another domain using Kerberos, a user's workstation first requests a ticket from a domain controller in its account domain to the server (hosting the resource) in the trusting domain. This ticket is then issued by an intermediary trusted by the workstation and the server. The workstation presents this trusted ticket to the server in the trusting domain for authentication.

The following figure and corresponding steps provide a detailed description of the Kerberos authentication process that is used when a computer running Windows 2000 Professional, Windows 2000 Server, XOX, or a member of the Windows Server 2003 family attempts to access resources from a server located in another domain.

The Kerberos authentication process between two domains within the same forest
  1. User1 logs on to Workstation1 using credentials from the child1.microsoft.com domain. As part of this process, the authenticating domain controller issues User1 a ticket-granting ticket (TGT). This ticket is required to be authenticated to resources. The user then attempts to access a shared resource (\\fileserver1\share) on a file server located in the child2 domain.
  2. Workstation1 contacts the Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 service principal name (SPN).
  3. ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the forest contain this SPN. The global catalog sends the requested information back to ChildDC1.
  4. ChildDC1 sends the referral to Workstation1.
  5. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ChildDC2) in the Child2 domain. ForestRootDC1 sends the referral to Workstation 1.
  6. Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for the user to gain access to FileServer1.
  7. Now that Workstation1 has a service ticket, it sends the service ticket to FileServer1, which reads the user's security credentials and constructs an access token accordingly.

Each domain has its own set of security policies that do not cross from one domain to another. For more information, see Domains.

Planning your access control strategy for multiple domains

It is recommended that you carefully plan the most efficient access control strategy for your organization's resource needs. Your design and implementation of security groups throughout each domain in a single forest will be an important factor to consider during your planning. For information about planning an access control strategy for multiple forests, see Accessing resources across forests.

It is important to understand the following security group concepts before you begin the planning process:

  • Security groups. User rights can be applied to groups in Active Directory while permissions can be assigned to security groups on member servers hosting a resource. For more information, see Security groups.
  • Group nesting. The ability to nest security groups is dependent on group scopes and domain functionality. For more information, see Nesting groups.
  • Group scope. Group scope helps determine the domain-wide and forest-wide access boundaries of security groups. For more information, see Group scope.
  • Domain functionality. The domain functional level of the trusting and trusted domains can affect group functionality such as group nesting. For more information, see Domain and forest functionality.

Once you have gained a thorough understanding of security group concepts, determine the resource needs of each department and geographical division to assist you with the planning effort.

Best practices for controlling access to shared resources across domains

By carefully using domain local, global, and universal groups, administrators can more effectively control access to resources located in other domains. Consider the following best practices:

  • Organize domain users based on administrative needs, such as their locations or departments, and then create a global group, and add the appropriate user accounts as members.

    For example, add all employee user accounts in the Sales department to the Sales Department global group, and add all employee user accounts in the Accounting Department to the Accounting Department global group.

  • Create a domain local group, and add all global groups from the other domain that need the same access to a resource in your domain.

    For example, employees in the Sales Department and Accounting Department global groups located in DomainA use similar print resources located in DomainB. To make future administration changes more flexible, create a domain local group called Print Resources in DomainB, and add as members both the Sales Department and Accounting Department global groups in DomainA.

  • Assign the required permissions on the shared resource to the domain local group.

    For example, assign permissions to the Print Resources domain local group located in DomainB so that its members, including the Sales Department and Accounting Department groups from DomainA, can access the printer located in DomainB.

Selective authentication between domains in an external trust

Using Active Directory Domains and Trusts, you can determine the scope of authentication between two domains that are joined by an external trust. You can set selective authentication differently for outgoing and incoming external trusts. With selective trusts, administrators can make flexible access control decisions between external domains. For more information about how to set selective authentication, see To select the scope of authentication for users.

If you use domain-wide authentication on the incoming external trust, users in the second domain would have the same level of access to resources in the local domain as users who belong to the local domain. For example, if DomainA has an incoming external trust from DomainB and domain-wide authentication is used, any user from DomainB would be able to access any resource in DomainA (assuming that they have the required permissions).

If you set selective authentication on an incoming external trust, you need to manually assign permissions on each resource to which you want users in the second domain to have access. To do this, set a control access right Allowed to authenticate on an object for that particular user or group from the external domain.

When a user authenticates across a trust with the Selective authentication option enabled, an Other Organization security ID (SID) is added to the user's authorization data. The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is authenticated, if the Other Organization SID is not already present, then the server adds the This Organization SID. Only one of these special SIDs can be present in an authenticated user's context.

Administrators in each domain can add objects from one domain to access control lists (ACLs) on shared resources in the other domain. You can use the ACL editor to add or remove objects residing in one domain to ACLs on resources in the other domain. For more information about how to set permissions on resources, see To set permissions on a shared resource.

For information about setting authentication restrictions for multiple forests, see Accessing resources across forests.


Accessing resources across forests

When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests. For more information about routing authentication requests across forests, see Routing name suffixes across forests.

Before authentication protocols can follow the forest trust path, the service principal name (SPN) of the resource computer must be resolved to a location in the other forest. An SPN can be one of the following: the Domain Name System (DNS) name of a host, the DNS name of a domain, or the distinguished name of a service connection point object.

When a workstation in one forest attempts to access data on the resource computer in another forest, Kerberos contacts the domain controller for a service ticket to the SPN of the resource computer. Once the domain controller queries the global catalog and identifies that the SPN is not in the same forest as the domain controller, the domain controller sends a referral for its parent domain back to the workstation. At that point, the workstation queries the parent domain for the service ticket and follows the referral chain until it gets to the domain where the resource is located.

The following figure and corresponding steps provide a detailed description of the Kerberos authentication process that is used when computers running Windows 2000 Professional, XOX, Windows 2000 Server, or a member of the Windows Server 2003 family attempt to access resources from a computer located in another forest.

The Kerberos authentication process between two forests joined by a forest trust
  1. User1 logs on to Workstation1 using credentials from the child.microsoft.com domain. The user then attempts to access a shared resource on FileServer1 located in the msn.com forest.
  2. Workstation1 contacts the Key Distribution Center (KDC) on a domain controller in its domain (ChildDC1) and requests a service ticket for the FileServer1 SPN.
  3. ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the microsoft.com forest contain this SPN. Since a global catalog is limited to its own forest, the SPN is not found. The global catalog then checks its database for information about any forest trusts that are established with its forest, and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match. Once a match is found, the global catalog provides a routing hint back to ChildDC1.
  4. ChildDC1 sends a referral for its parent domain back to Workstation1.
  5. Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ForestRootDC2) in the forest root domain of the msn.com forest.
  6. Workstation1 contacts ForestRootDC2 in the msn.com forest for a service ticket to the requested service.
  7. ForestRootDC2 contacts its global catalog to find the SPN, and the global catalog finds a match for the SPN and sends it back to ForestRootDC2.
  8. ForestRootDC2 then sends the referral to child.msn.com back to Workstation1.
  9. Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for User1 to gain access to FileServer1.
  10. Now that workstation1 has a service ticket, it sends the server service ticket to FileServer1, which reads User1's security credentials and constructs an access token accordingly.

When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and stores the information in a TDO. Trusted namespaces include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. TDO objects are replicated to the global catalog. For more information about TDOs, see Trusts.

Routing hints

Routing hints are only used when all traditional authentication channels (local domain controller and then global catalog) have failed to produce a location of a SPN. Routing hints help direct authentication requests toward the destination forest.

When an SPN cannot be located in the domain from where the network logon request originated or from the global catalog database, the global catalog checks the forest trust TDO for trusted name suffixes located in the other forest that might match the suffix in the SPN. If a match is found, the forest root domain returns a routing hint back to the original source computer so that it can continue the SPN location process in the other forest.

Notes

  • Routing hints can only reference trusted name suffixes that are listed in the TDO for its forest trust. They do not verify the name suffix before sending the hint back to the original source computer.
  • Accessing NetBIOS names and Kerberos delegation across forest trusts is not supported. NTLM is fully supported and cannot be disabled.

Planning your access control strategy for multiple forests

It is recommended that you carefully plan the most efficient access control strategy for your organization's resource needs. Your design and implementation of security groups throughout each forest will be an important factor to consider during your planning. For information about planning an access control strategy for multiple domains, see Accessing resources across domains.

It is important to understand the following security group concepts before you begin the planning process:

  • Security groups. User rights can be applied to groups in Active Directory while permissions can be assigned to security groups on member servers hosting a resource. For more information, see Security groups.
  • Group nesting. The ability to nest security groups is dependent on groups scopes and domain functionality. For more information, see Nesting groups.
  • Group scope. Group scope helps determine the domain-wide and forest-wide access boundaries of security groups. For more information, see Group scope.
  • Domain functionality. The domain functional level of the trusting and trusted domains can affect group functionality such as group nesting. For more information, see Domain and forest functionality.

Once you have gained a thorough understanding of security group concepts, determine the resource needs of each department and geographical division to assist you with the planning effort.

Best practices for using security groups across forests

By carefully using domain local, global, and universal groups, administrators can more effectively control access to resources located in other forests. Consider the following best practices:

  • Organize domain users in each forest based on administrative needs, such as their geographical locations or departments, and then create a global group for each location or department, and then add the appropriate user accounts to it.

    For example, add all employee user accounts in the Sales department to the Sales Department global group, and add all employee user accounts in the Accounting Department to the Accounting Department global group.

    When implementing an access control strategy across forests, global groups in one forest are used primarily for adding to universal groups located in another forest.

  • Create a universal group in the resource forest, and then add all global groups from the other forest (or forests) that need similar access as members of the universal group.

    For example, both the employees in the Sales Department and Accounting Department global groups located in ForestA use similar print resources located in ForestB. Create a universal group called Print Users in Other Forests in ForestB, and add both the Sales Department and Accounting Department global groups from ForestA as members.

    Universal groups are used primarily to group together two or more global groups (possibly from other forests) into one group for the resource domain.

  • From the resource forest, create a domain local group in the domain where the resource resides (in the resource forest), and then add all applicable universal groups as members.

    For example, both the employees in the Sales Department in ForestA and the Manufacturing Department in ForestC use similar print resources located in ForestB. A universal group for all Sales employees is created (Sales) in ForestA and all Manufacturing employees are added to a new universal group (Manufacturing) in ForestC. Both of the Sales and Manufacturing universal groups can then be added to a domain local group called Print Resources in the resource domain (in ForestB).

    When implementing a access control strategy across forests, domain local groups are used primarily to group together universal groups (from other forests) into one group for ease of administration.

  • Assign the required permissions to the domain local group on the shared resource in ForestA.

    For example, assign the required permissions on the print server to the Print Resources domain local group in the resource domain in ForestB. Because the Sales employees group in ForestA and the Manufacturing employees group in ForestC are members of the Print Resources domain local group in ForestB, they will also be assigned the required permissions.

    For more information, see To set permissions on a shared resource.

Selective authentication between forests

Using Active Directory Domains and Trusts, you can determine the scope of authentication between two forests that are joined by a forest trust. You can set selective authentication differently for outgoing and incoming forest trusts. With selective trusts, administrators can make flexible forest-wide access control decisions. For more information about how to set selective authentication, see To select the scope of authentication for users.

If you use forest-wide authentication on an incoming forest trust, users from the outside forest have the same level of access to resources in the local forest as users who belong to the local forest. For example, if ForestA has an incoming forest trust from ForestB and forest-wide authentication is used, users from ForestB would be able to access any resource in ForestA (assuming they have the required permissions).

If you decide to set selective authentication on an incoming forest trust, you need to manually assign permissions on each domain and resource to which you want users in the second forest to have access. To do this, set a control access right Allowed to authenticate on an object for that particular user or group from the second forest.

When a user authenticates across a trust with the Selective authentication option enabled, an Other Organization security ID (SID) is added to the user's authorization data. The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is authenticated, then the server to which he authenticates adds the This Organization SID if the Other Organization SID is not already present. Only one of these special SIDs can be present in an authenticated user's context.

Administrators in each forest can add objects from one forest to access control lists (ACLs) on shared resources in the other forest. You can use the ACL editor to add or remove objects residing in one forest to ACLs on resources in another forest. For more information about how to set permissions on resources, see To set permissions on a shared resource.

For information about setting authentication restrictions for external domains, see Accessing resources across domains.


Routing name suffixes across forests

Name suffix routing is a mechanism used to manage how authentication requests are routed across Windows Server 2003 forests that are joined together by forest trusts. To simplify administration of authentication requests, when a forest trust is initially created, all unique name suffixes are routed by default. A unique name suffix is a name suffix within a forest, such as a user principal name (UPN) suffix, service principal name (SPN) suffix, or DNS forest or domain tree name, that is not subordinate to any other name suffix. For example, the DNS forest name microsoft.com is a unique name suffix within the microsoft.com forest.

Forests can contain multiple unique name suffixes, and all children of unique name suffixes are routed implicitly. In Active Directory Domains and Trusts, name suffixes appear with an asterisk (*) at the beginning because of this. For example, if your forest uses *.microsoft.com as a unique name suffix, then authentication requests for all children of microsoft.com (*.child.microsoft.com) will be routed because the child domains are part of the microsoft.com name suffix.

If a forest trust exists between two forests, then name suffixes that do not exist in one forest can be used to route authentication requests to a second forest. When a new child name suffix (*.child.widgets.com) is added to a unique name suffix (*.widgets.com), the child name suffix will inherit the routing configuration of the unique name suffix to which it belongs. Any new unique name suffixes that are created after a forest trust has been established will be visible in the forest trust Properties dialog box after you verify the trust. However, routing for those new unique name suffixes will be disabled by default. For more information about how to verify a trust, see To verify a trust.

When a duplicate name suffix is detected, the routing for the newest name suffix will be disabled by default. For more information about how to route name suffixes, see To enable or disable an existing name suffix from routing. Administrators can use the forest trust Properties dialog box to manually prevent authentication requests for specific name suffixes from being routed to a forest.

Notes

  • Do not add the @ sign to the UPN suffix or a user name. When authentication requests are routed to a trusted forest, all characters before the first @ symbol are interpreted as the user name and everything after the first @ symbol as the UPN suffix.
  • The Local Security Authority (LSA) will block routing to any UPN suffix that is not a valid DNS name. For example, adding an @ symbol to a UPN suffix will cause it to automatically be disabled.

Collision detection

When two Windows Server 2003 forests are linked by a forest trust, there is a possibility that unique name suffixes existing in one forest might collide with unique name suffixes located in the second forest. Collision detection guarantees that each name suffix will only be routed to a single forest.

Active Directory Domains and Trusts will detect a name suffix conflict when:

  • The same Domain Name System (DNS) name is already in use.
  • The same NetBIOS name is already in use.
  • A domain security ID (SID) conflicts with another name suffix SID.

When a name suffix in a forest conflicts with a new forest trust partner or when a name suffix in an existing forest trust conflicts with a new forest trust partner, the name will be disabled in the new trust. For example, a conflict will occur if one forest is named widgets.com and the second forest is named sales.widgets.com. Despite the name suffix conflict, routing will still work for any other unique name suffixes in the second forest.

For another example, assume that the msn.com forest needs to establish a two-way, forest trust with the widgets.com forest. Both msn.com and widgets.com have identical UPN suffixes of microsoft.com. During the creation of the two-way, forest trust, the New Trust Wizard will detect and display the conflict between the two UPN name suffixes and then create the forest trust.

If Active Directory Domains and Trusts detects a name suffix conflict with a trust partner domain, access to that domain from outside the forest may be denied. However, access to the conflicted domain from within its forest will function normally.

For example, if the domain widgets.com exists in both the msn.com and microsoft.com forests, users within the msn.com forest will be able to access resources in widgets.com domain that resides in the msn.com forest. However, users in the msn.com forest will be denied access to resources in the widgets.com domain located in the microsoft.com forest.

Conflicts will be listed in Active Directory Domains and Trusts, in the forest trust Properties dialog box, on the Name Suffix Routing tab. If a name suffix conflict is detected during the creation of the forest trust, then the New Trust Wizard will prompt you to save a log file of the conflicts. You can also save a log file after a trust has been created. For more information about how to save this log file, see To change the routing status of a name suffix.

If a NetBIOS or domain SID conflict exists, Active Directory Domains and Trusts identifies the name suffixes routing status as enabled or disabled with exceptions, as appropriate. The details about where the conflict exists are listed in the log file.

You can also use the Netdom command-line tool to list all routed names and to enable and disable routing for NetBIOS names and SIDs. For example, a forest named microsoft.com has a forest trust with widgets.com and you also need to add a forest trust to msn.com. Both widgets.com and msn.com have child domains with the NetBIOS name of SALES (and DNS names of USsales.widgets.com and sales.msn.com).

After you create the new trust to msn.com, routing to the SALES domain name in msn.com will be disabled. If you need to use the name SALES to route to the msn.com forest but don't need to use it to the widgets.com forest, you can use Netdom to disable SALES in widgets.com, and then enable it in msn.com.

For information about Netdom, see Active Directory Support tools.


Understanding sites and replication

This section covers:

  • Sites overview
  • Replication overview
  • How replication works
  • Replication within a site
  • Replication between sites
  • When to establish a single or separate sites
  • Bandwidth
  • Managing replication


Sites overview

Sites in Active Directory® represent the physical structure, or topology, of your network. Active Directory uses topology information, stored as site and site link objects in the directory, to build the most efficient replication topology. You use Active Directory Sites and Services to define sites and site links. A site is a set of well-connected subnets. Sites differ from domains; sites represent the physical structure of your network, while domains represent the logical structure of your organization.

Using sites

Sites help facilitate several activities within Active Directory, including:

  • Replication. Active Directory balances the need for up-to-date directory information with the need for bandwidth optimization by replicating information within a site more frequently than between sites. You can also configure the relative cost of connectivity between sites to further optimize replication. For more information, see Replication between sites and Managing replication.
  • Authentication. Site information helps make authentication faster and more efficient. When a client logs on to a domain, it first searches its local site for a domain controller to authenticate against. By establishing multiple sites, you can ensure that clients authenticate against domain controllers nearest to them, reducing authentication latency and keeping traffic off WAN connections.
  • Active Directory–enabled services. Active Directory–enabled services can leverage site and subnet information to enable clients to locate the nearest server providers more easily. For information about services, see Services.

Defining sites using subnets

In Active Directory, a site is a set of computers well-connected by a high-speed network, such as a local area network (LAN). All computers within the same site typically reside in the same building, or on the same campus network. A single site consists of one or more Internet Protocol (IP) subnets. Subnets are subdivisions of an IP network, with each subnet possessing its own unique network address. A subnet address groups neighboring computers in much the same way that postal codes group neighboring postal addresses. The following figure shows several clients within a subnet that defines an Active Directory site.

Several clients contained within a subnet that defines an Active Directory site.

Sites and subnets are represented in Active Directory by site and subnet objects, which you create through Active Directory Sites and Services. Each site object is associated with one or more subnet objects.

For information about creating sites, see To create a site.

For information about creating subnets, see To create a subnet.

For information about subnets, see "Introduction to TCP/IP" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

Assigning computers to sites

Computers are assigned to sites based on their Internet Protocol (IP) address and subnet mask. Site assignment is handled differently for clients and member servers than for domain controllers. For a client, site assignment is dynamically determined by its IP address and subnet mask during logon. For a domain controller, site membership is determined by the location of its associated server object in Active Directory. For more information, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

For information about associating subnets with sites, see To associate a subnet with a site.

For information about establishing single or multiple sites, see When to establish a single or separate sites.

Understanding sites and domains

In Active Directory, sites map the physical structure of your network, while domains map the logical or administrative structure of your organization. This separation of physical and logical structure provides the following benefits:

  • You can design and maintain the logical and physical structures of your network independently.
  • You do not have to base domain namespaces on your physical network.
  • You can deploy domain controllers for multiple domains within the same site. You can also deploy domain controllers for the same domain in multiple sites.
A domain can contain multiple sites, and a site can contain multiple domains.

For more information about domains, see Domains.


Replication overview

Except for very small networks, directory data must reside in more than one place on the network to be equally useful to all users. Through replication, the Active Directory® directory service maintains replicas of directory data on multiple domain controllers, ensuring directory availability and performance for all users. Active Directory uses a multimaster replication model, allowing you to make directory changes at any domain controller, not just at a designated primary domain controller. Active Directory relies on the concept of sites to help keep replication efficient, and on the Knowledge Consistency Checker (KCC) to automatically determine the best replication topology for the network.

Organizing data for replication

Data is stored on each domain controller in the directory store, which is divided logically into specific directory partitions. Each partition stores a different type of directory data, either domain data, forest schema data, forest configuration data, or application data. All domain controllers within a forest hold a replica of the schema and configuration partitions for that forest, and all domain controllers within a particular domain hold a replica of the domain partition for their domain. Application directory partitions hold directory data specific to a particular application and can be stored by domain controllers belonging to different domains. Changes to each directory partition are replicated to all other domain controllers that hold a copy of that partition. For more information, see Directory data store.

Replication also ensures the availability of the global catalog throughout the entire forest. The global catalog is a searchable directory store containing data about every object in all domains. The global catalog is stored by domain controllers for which the global catalog has been enabled. For more information, see Global catalog replication.

Improving replication efficiency with sites

To help make replication more efficient, Active Directory relies on sites. Sites, defined as groups of well-connected computers, determine how directory data is replicated. Active Directory replicates directory information within a site more frequently than among sites. This way, the best connected domain controllers, those most likely to need particular directory information, receive replicated updates first. The domain controllers in other sites also receive the changes, but less frequently, reducing network bandwidth consumption. For more information, see How replication works and Sites overview.

Determining the replication topology

The Knowledge Consistency Checker (KCC), a process running on each domain controller, automatically identifies the most efficient replication topology for your network, based on information you provide about your network in Active Directory Sites and Services. The KCC regularly recalculate the replication topology to adjust for any network changes that have occurred. The KCC of one domain controller within each site (the intersite topology generator) determines the intersite replication topology. For more information about the KCC, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

Replication enhancements in the Windows Server 2003 family

The Microsoft® Windows® Server 2003 family includes enhancements to make replication both more efficient, as well as more scalable aross a larger number of domains and sites. These include refinements in memory usage, enhancements to the Windows 2000 spanning tree algorithm, a completely new spanning tree algorithm for Windows Server 2003 forests, and a new load balancing tool (included in the Windows Resource Kit tools).

In a forest set to the Windows 2000 functional level, the replication enhancements provide gains in replication efficiency and scalability, even when sites and domains contain domain controllers running Windows 2000. If a site contains at least one domain controller running Windows Server 2003, then a domain controller running Windows Server 2003 assumes the intersite topology generator role for the site, allowing the enhancements to take effect.

In a forest set to the Windows Server 2003 functional level, the new Windows Server 2003 spanning tree algorithm goes into effect for larger gains in both efficiency and scalability. For example, using the orginal spanning tree algorithm from Windows 2000, one domain can contain up to 300 sites. With the new Windows Server 2003 algorithm, one domain can contain up to at least 3,000 sites. In the new algorithm, the intersite toplogy generator in each site uses a randomized selection process to determine the bridgehead servers for the site. This selection process more evenly distributes the bridgehead replication workload among domain controllers in a site, resulting in much better effiency (particularly in hub sites with a number of domain controllers). By default, the randomized selection process takes place only when new connection objects are added to the site. However, a new Windows Resource Kit tool, called adlb.exe, can be run to rebalance the load each time changes occur in the topology or in the number of domain controllers in the site. In addition, adlb can stagger schedules so that the outbound replication load for each server is spread out evenly across time. For more information, see "Tools and Technical References" Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


How replication works

To keep directory data on all domain controllers consistent and up to date, Active Directory replicates directory changes on a regular basis. Replication occurs over standard network protocols, uses change tracking information to prevent unnecessary replication, and uses linked value replication to improve efficiency.

Transferring replication data

Active Directory uses remote procedure call (RPC) over Internet Protocol (IP) to transfer replication data between domain controllers. RPC over IP is used for both intersite and intrasite replication. To keep data secure while in transit, RPC over IP replication uses both authentication (using the Kerberos V5 authentication protocol) and data encryption.

When a direct or reliable IP connection is not available, replication between sites can be configured to use the Simple Mail Transfer Protocol (SMTP). However, SMTP replication functionality is limited, and requires an enterprise certification authority (CA). SMTP can only be used to replicate the configuration, schema and application directory partitions, and does not support the replication of domain directory partitions. For more information, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

Preventing unnecessary replication

Once a domain controller has processed a directory change from another domain controller successfully, it should not try to replicate those changes back to the domain controller that sent the change. In addition, a domain controller should avoid sending updates to another domain controller if the target domain controller has already received that same update from a different replication partner. To prevent such unnecessary replication, Active Directory uses change tracking information stored in the directory. For information about change tracking, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

Resolving conflicting changes

It is possible for two different users to make changes to the exact same object property and to have these changes applied at two different domain controllers in the same domain before replication of either change occurs. In such a case, both changes are replicated as new changes, creating a conflict. To resolve this conflict, domain controllers that receive these conflicting changes examine the attribute data contained within the changes, each of which holds a version and a timestamp. Domain controllers will accept the change with the higher version and discard the other change. If the versions are identical, domain controllers will accept the change with the more recent timestamp.

Improving replication efficiency

Introduced in the Windows Server 2003 family, linked value replication allows individual values of a multivalued attribute to be replicated separately. In Windows 2000, when a change was made to a member of a group (one example of a multivalued attribute with linked values) the entire group had to be replicated. With linked value replication, only the group member that has changed is replicated, and not the entire group. To enable linked value replication, you must raise the forest functional level to Windows Server 2003. For more information about forest functional levels, see Domain and forest functionality. For more information about multivalued attributes, see Schema.

For more information about how replication works, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Replication within a site

Active Directory handles replication within a site, or intrasite replication, differently than replication between sites because bandwidth within a site is more readily available. The Active Directory Knowledge Consistency Checker (KCC) builds the intrasite replication topology using a bidirectional ring design. Intrasite replication is optimized for speed, and directory updates within a site occur automatically on the basis of change notification. Unlike replication data travelling between sites, directory updates replicated within a site are not compressed.

For information about intersite replication, see Replication between sites and How replication works.

Building the intrasite replication topology

The Knowledge Consistency Checker (KCC) on each domain controller automatically builds the most efficient replication topology for intrasite replication, using a bidirectional ring design. This bidirectional ring topology attempts to create at least two connections to each domain controller (for fault tolerance) and no more than three hops between any two domain controllers (to reduce replication latency). To prevent connections of more than three hops, the topology can include shortcut connections across the ring. The KCC updates the replication topology regularly.

Note

  • The KCC actually creates a separate replication topology for each directory partition (schema, configuration, domain, application). Within a single site, these topologies are usually identical for all partitions hosted by the same set of the domain controllers.

Determining when intrasite replication occurs

Directory updates made within a site are likely to have the most direct impact on local clients, so intrasite replication is optimized for speed. Replication within a site occurs automatically on the basis of change notification. Intrasite replication begins when you make a directory update on a domain controller. By default, the source domain controller waits 15 seconds and then sends an update notification to its closest replication partner. If the source domain controller has more than one replication partner, subsequent notifications go out by default at 3 second intervals to each partner. After receiving notification of a change, a partner domain controller sends a directory update request to the source domain controller. The source domain controller responds to the request with a replication operation. The 3 second notification interval prevents the source domain controller from being overwhelmed with simultaneous update requests from its replication partners.

For some directory updates in a site, the 15 second waiting time does not apply and replication occurs immediately. Known as urgent replication, this immediate replication applies to critical directory updates, including the assigning of account lockouts and changes in the account lockout policy, the domain password policy, or the password on a domain controller account.

For more information about intrasite replication, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Replication between sites

Active Directory handles replication between sites, or intersite replication, differently than replication within sites because bandwidth between sites is usually limited. The Active Directory Knowledge Consistency Checker (KCC) builds the intersite replication topology using a least-cost spanning tree design. Intersite replication is optimized for bandwidth efficiency, and directory updates between sites occur automatically based on a configurable schedule. Directory updates replicated between sites are compressed to preserve bandwidth.

For information about intrasite replication, see Replication within a site.

For information about site design, see "Designing the Site Topology" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

Building the intersite replication topology

Active Directory automatically builds the most efficient intersite replication topology using information you provide (through Active Directory Sites and Services) about your site connections. The directory stores this information as site link objects. One domain controller per site, called the intersite topology generator, is assigned to build the topology. A least-cost spanning tree algorithm is used to eliminate redundant replication paths between sites. The intersite replication topology is updated regularly to respond to any changes that occur in the network. You can control intersite replication through the information you provide when you create your site links. For more information, see Managing replication.

Determining when intersite replication occurs

Active Directory preserves bandwidth between sites by minimizing the frequency of replication and by allowing you to schedule the availability of site links for replication. By default, intersite replication across each site link occurs every 180 minutes (3 hours). You can adjust this frequency to match your specific needs. Be aware that increasing this frequency increases the amount of bandwidth used by replication. In addition, you can schedule the availability of site links for use by replication. By default, a site link is available to carry replication traffic 24 hours a day, 7 days a week. You can limit this schedule to specific days of the week and times of day. You can, for example, schedule intersite replication so that it only occurs after normal business hours. For more information, see To configure site link replication frequency and To configure site link replication availability.

Notes

  • With certain restrictions, you can use the Simple Mail Transfer Protocol (SMTP) for replicating to sites that do not have a direct or reliable Internet Protocol (IP) connection. For more information, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • Intersite replication through a firewall or virtual private network requires some special considerations. For more information, see Active Directory at the Microsoft Web site. (http://www.microsoft.com/)


When to establish a single or separate sites

You can optimize the replication efficiency and reduce the administrative overhead of your network by establishing sites appropriately. The most effective number of sites depends on the physical design of your network. When you first create a new forest, a single, default Active Directory site (called Default-Site-First-Name) is created that represents your entire network. A forest or domain consisting of a single site can be very efficient for a single location network connected completely by high-speed bandwidth. If your forest or domain contains multiple geographic locations that communicate over low-speed wide area network (WAN) connections, establishing multiple sites gives you more granular control of replication behavior, reduces authentication latency, and reduces network traffic on the WAN.

For information about sites, see Sites overview.

For information about designing a site topology, see "Designing the Site Topology" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

Why bandwidth is important

Within a site, bandwidth affects how efficiently replication can work. The frequency with which intrasite replication occurs requires high-speed bandwidth to function most effectively. So before you a create new site, you should make sure that high-speed bandwidth connects all computers within the site candidate. Any area where domain controllers are connected by 10 megabits per second (Mbps) or more of bandwidth is a good site candidate.

When to establish a single site

If you have a single LAN consisting of a single subnet, or if your network contains multiple subnets connected by a high-speed backbone, establishing a single site replication topology can provide the following benefits:

  • Simplified replication management
  • Prompt directory updates between all domain controllers
A single site topology allows all replication on your network to occur as intrasite replication, which requires no manual replication configuration. A single site design also allows all domain controllers to remain very current with respect to directory changes, because directory updates are replicated almost immediately. For more information, see Replication within a site. For information about creating sites, see To create a site.

When to establish multiple sites

When your network consists of multiple geographic locations connected by a WAN, establishing separate sites for each location provides the following benefits:

  • Efficient use of WAN bandwidth for replication
  • Granular control of replication behavior
  • Reduction in authentication latency

Physically separate network locations typically communicate over WAN connections, which are most often characterized by low-speed bandwidth. By creating a separate site for each physical location on your network, you ensure that domain controllers communicating over WAN connections use intersite replication, which is specifically designed for efficiency on low bandwidth connections. For more information, see Replication between sites.

With multiple sites, you have more granular control of replication behavior through several configurable intersite replication settings. These settings include the relative cost of different replication paths, the domain controllers associated with each site, the subnets associated with each site, the frequency of directory update transfers, and the availability of connections for use by replication. For more information, see Managing replication.

A network client logging on to a domain must contact a domain controller as part of the authentication process, first looking within its own site. If the site includes two or more physically separate network locations, the client may authenticate against a domain controller across a WAN connection. Authentication across a WAN introduces a delay in the authentication process. By placing physically separate network locations into separate Active Directory sites, you can ensure that clients first attempt to authenticate against a domain controller in their own site.


Bandwidth

Bandwidth is the most important practical consideration affecting intrasite replication on your network. Although sites are conveniently defined by subnets, it is important to understand that the reason for this choice is that subnets are typically well-connected. This means that subnets are generally, but not always, an effective way to determine sites.

To organize your sites effectively, consider replication requirements and available connectivity. Find a balance that ensures domain controllers in the same site are sufficiently well-connected to handle the frequent exchange of directory information, while not exacting what you consider to be excessive costs (such as high financial expense or compromised network performance).

When considering bandwidth, you may want to combine several subnets into one site, or split one subnet among several sites, such as in the following instances:

  • One large subnet split into three subnets.
    You have very poorly connected computers, including several domain controllers in one subnet. Create several smaller subnets that are better connected than they were as one large subnet. For this to be effective, each new subnet should contain a domain controller.
  • Several small subnets combined into fewer, larger subnets.
    You have several subnets that are all well-connected or you have fewer domain controllers than subnets, but you want several subnets to be in a single site. To do this, add multiple subnets to one site.

For more information about how bandwidth may affect the way you configure sites, see Replication between sites.


Managing replication

Active Directory relies on site configuration information to manage and optimize the process of replication. Active Directory provides automatic configuration of these settings in some cases. In addition, you can configure site-related information for your network using Active Directory Sites and Services. Configurable information includes settings for site links, site link bridges, and bridgehead servers.

Configuring site links

You can use site link settings to control replication between sites. Configurable settings include the relative cost of each site link, the frequency of replication on each site link, and the schedule availability of each site link for replication. For information about site links, see Replication between sites.

Site link cost

The cost of a site link determines the relative preference of the Active Directory Knowledge Consistency Checker (KCC) for using a site link in the replication topology. The higher the cost of the site link, the lower will be the KCC's preference for using the site link. For example, if you have two site links, site link A and site link B, and you set the cost of site link A to 150 and the cost of site link B to 200, the KCC will prefer to use site link A in the replication topology. By default, the cost of a newly created site link is 100. For information about setting site link cost, see To configure site link cost. For information about the KCC, see Replication overview.

Replication frequency

The replication frequency of a site link determines how often replication occurs over that site link. By default, the replication frequency for a site link is 180 minutes, meaning that replication occurs over that site link every 180 minutes, or three hours. Using Active Directory Sites and Services, you can set the replication frequency from 15 minutes to 10,080 minutes (one week). A site link must be available for any replication to occur. If a site link is not available when the number of minutes between replication updates has passed, no replication will occur. For more information, see To configure site link replication frequency.

Site link availability

The availability schedule for a site link determines during which hours or days of the week a site link can be used for replication. By default, a site link is always available for replication, 24 hours a day and 7 days a week. You can change this schedule, for example, to exclude business hours during which your network is busy handling other types of traffic. Or, you can exclude particular days on which you do not want replication to occur. Scheduling information is ignored by site links that use the Simple Mail Transfer Protocol (SMTP) for replication. For more information, see To configure site link replication availability.

Configuring site link bridges

By default, all site links are bridged, or transitive. This allows any two sites that are not connected by an explicit site link to communicate directly, through a chain of intermediary site links and sites. One advantage to bridging all site links is that your network is easier to maintain because you do not need to create a site link to describe every possible path between pairs of sites.

Generally, you can leave automatic site link bridging enabled. However, you might want to disable automatic site link bridging and create site link bridges manually just for specific site links, in the following cases:

  • Your network is not fully routed (not every domain controller can directly communicate with every other domain controller).
  • You have a network routing or security policy in place that prevents every domain controller from being able to directly communicate with every other domain controller.
  • Your Active Directory design includes a large number of sites. For more information, see the Active Directory Branch Office Planning Guide at the Microsoft Web site. (http://www.microsoft.com/)

For more information about site link bridges and their affects on replication, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

For information about disabling automatic site link bridging, see To enable or disable site link bridges.

For information about creating a site link bridge manually, see To create a site link bridge.

Configuring preferred bridgehead servers

When the KCC constructs the intersite replication topology, it automatically assigns one or more bridgehead servers for each site to ensure that directory changes only need to be replicated across a site link one time. It is recommended that you allow the KCC to make the bridgehead server assignments. You can make the bridgehead server assignments manually through Active Directory Sites and Services. However, doing so can potentially disrupt replication if one of your manually assigned bridgehead servers becomes unavailable. For more information, see "Active Directory Replication" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

For information about manually configuring a bridgehead server, see To designate a preferred bridgehead server.


Understanding the global catalog

This section covers:

  • The role of the global catalog
  • Global catalog replication
  • Customizing the global catalog
  • Global catalogs and sites


The role of the global catalog

A global catalog is a domain controller that stores a copy of all Active Directory objects in a forest. The global catalog stores a full copy of all objects in the directory for its host domain and a partial copy of all objects for all other domains in the forest, as shown in the following figure.

Domain controller enabled as a global catalog

The partial copies of all domain objects included in the global catalog are those most commonly used in user search operations. These attributes are marked for inclusion in the global catalog as part of their schema definition. Storing the most commonly searched upon attributes of all domain objects in the global catalog provides users with efficient searches without affecting network performance with unnecessary referrals to domain controllers.

You can manually add or remove other object attributes to the global catalog by using the Active Directory Schema snap-in. For more information, see Customizing the global catalog.

A global catalog is created automatically on the initial domain controller in the forest. You can add global catalog functionality to other domain controllers or change the default location of the global catalog to another domain controller. For more information, see To enable or disable a global catalog.

A global catalog performs the following directory roles:

  • Finds objects

    • A global catalog enables user searches for directory information throughout all domains in a forest, regardless of where the data is stored. Searches within a forest are performed with maximum speed and minimum network traffic.

    When you search for people or printers from the Start menu or choose the Entire Directory option within a query, you are searching a global catalog. Once you enter your search request, it is routed to the default global catalog port 3268 and sent to a global catalog for resolution. For more information, see Finding directory information and "Finding information in Active Directory" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

  • Supplies user principal name authentication

    • A global catalog resolves user principal names (UPNs) when the authenticating domain controller does not have knowledge of the account. For example, if a user’s account is located in example1.microsoft.com and the user decides to log on with a user principal name of user1@example1.microsoft.com from a computer located in example2.microsoft.com, the domain controller in example2.microsoft.com will be unable to find the user’s account, and will then contact a global catalog to complete the logon process. For more information, see Active Directory naming.

  • Supplies universal group membership information in a multiple domain environment

    • Unlike global group memberships, which are stored in each domain, universal group memberships are only stored in a global catalog. For example, when a user who belongs to a universal group logs on to a domain that is set to the Windows 2000 native domain functional level or higher, the global catalog provides universal group membership information for the user’s account at the time the user logs on to the domain.

    If a global catalog is not available when a user logs on to a domain set to the functional level of Windows 2000 native or higher, the computer will use cached credentials to log on the user if the user has logged on to the domain previously. If the user has not logged on to the domain previously, the user can only log on to the local computer. However, if a user is a member of the Domain Admins group, the user can always log on to the domain, even when a global catalog is not available. For more information about universal groups, see Group scope. For more information about universal groups and replication, see Global catalog replication and Global catalogs and sites.

    Note

    • When there is only one domain in a forest, it is not necessary for users to obtain universal group memberships from a global catalog when logging on. This is because Active Directory can detect that there are no other domains in the forest and will prevent a query to the global catalog for this information.
  • Validates object references within a forest

    • A global catalog is used by domain controllers to validate references to objects of other domains in the forest. When a domain controller holds a directory object with an attribute containing a reference to an object in another domain, this reference is validated using a global catalog.


Global catalog replication

Replication of the global catalog ensures that users throughout the forest have fast access to information about every object in the forest. The default attributes that make up the global catalog provide a baseline of the most commonly searched attributes. These attributes are replicated to the global catalog as part of normal Active Directory replication.

The replication topology for the global catalog is generated automatically by the Knowledge Consistency Checker (KCC). However, the global catalog is replicated only to other domain controllers that have been designated as global catalogs. Global catalog replication is affected both by the attributes marked for inclusion in the global catalog, and by universal group memberships.

Adding attributes

Active Directory defines a base set of attributes for each object in the directory. Each object and some of its attributes (such as universal group memberships) are stored in the global catalog. Using the Active Directory Schema snap-in, you can specify additional attributes to be kept in the global catalog.

In Windows 2000 forests, extending the partial attribute set causes a full synchronization of all object attributes stored in the global catalog (for all domains in the forest). In a large, multi-domain forest, this synchronization can cause significant network traffic. Between domain controllers enabled as global catalogs that are running Windows Server 2003, only the newly added attribute is replicated. For more information about adding attributes to the global catalog, see Customizing the global catalog.

Preventing unpredictable access to global catalog data

Special security consideration should be given when specifying permissions on domain data that is also replicated to the global catalog. When a user connects to a global catalog, an impersonation token is created for the user, which is used in subsequent access control decisions on the global catalog. The user's universal, global and domain local group memberships are represented in this token. However, only domain local groups from the domain that the domain controller hosting the global catalog (to which the user has connected) belongs to and of which the user is a member show up in the user's token. Domain local groups in the user's domain (and in other domains) of which the user is a member do not show up in the access token.

A global catalog stores a replicated, read-only copy of all objects in the forest and a partial set of each object's attributes, including the security descriptor for each object. The security descriptor contains a discretionary access control list (DACL), which specifies permissions on the object. When a user connects to a global catalog and tries to access an object, an access check is performed based on the user's token and the object's DACL. Any permissions specified in the object's DACL for domain local groups that are not from the domain that the domain controller hosting the global catalog (to which the user has connected) belongs to, will be ineffective because only domain local groups from the global catalog's domain of which the user is a member are represented in the user's access token. As a result, a user may be denied access when access should have been granted, or allowed access when access should have been denied.

As a best practice, you should avoid using domain local groups when assigning permissions on Active Directory objects, or be aware of the implications if you do use them. To prevent unauthorized access to global catalog data, use global groups or universal groups instead. For information about global and universal groups, see Group scope.

How universal groups affect global catalog replication

Groups with universal scope, and their members, are listed exclusively in the global catalog. Groups with global or domain local scope are also listed in the global catalog, but their members are not. This reduces the size of the global catalog and the replication traffic associated with keeping the global catalog up to date. You can improve network performance by using groups with global or domain local scope for directory objects that will change frequently.

When you first create a universal group, you do so from any domain that is set to the domain functional level of Windows 2000 or higher. The universal group temporarily resides in the domain directory partition from where the group was created until the global catalog queries the domain for changes. Once the global catalog acquires the new object, changes are replicated to other global catalogs in the forest.

For more information about domain functional levels, see Understanding domain and forest functionality.


Customizing the global catalog

There may be instances where you will need to customize the global catalog to include additional attributes. However, you will want to carefully consider your options as changes to attributes can impact network traffic. By default, the global catalog contains an object’s most common attributes for every object in the entire forest, which applications and users can query. For example, you can find a user by first name, last name, e-mail address, or other common properties of a user account.

To add additional searchable attributes to the global catalog, administrators can use the Active Directory Schema snap-in. For more information about adding additional attributes to the global catalog, see To add an attribute to the global catalog.

When determining whether or not to add an attribute to the global catalog, consider only adding additional attributes that are frequently queried and referenced by users or applications across the enterprise. Also consider how frequently an attribute gets updated during replication. Attributes that are stored in the global catalog are replicated to every global catalog in the forest. The smaller the attribute, the lower the impact of that replication. If the attribute is large, but very seldom changes, it will have a smaller replication impact than a small attribute that changes often.

For more information about attribute definitions, see the Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).

Important

  • It is strongly recommended that you use global groups or universal groups instead of domain local groups when specifying permissions on domain directory partition objects replicated to the global catalog. For more information, see Global catalog replication.

Notes

  • In Windows 2000, adding a new attribute to the global catalog causes a full synchronization of all of the domain data from all of the domains in the forest. In a large, multi-domain Windows 2000 forest, this synchronization can cause significant network traffic. Between domain controllers enabled as global catalogs that are running Windows Server 2003, only the newly added attribute is replicated.
  • When deciding whether or not to include an attribute in the global catalog, remember that you are trading increased replication and increased disk storage on global catalogs for potentially faster query performance.


Global catalogs and sites

To optimize network performance in a multiple site environment, consider adding global catalogs for select sites. In a single site environment, a single global catalog is usually sufficient to cover common Active Directory queries. The following table will help you determine whether your multiple site environment will benefit using additional global catalogs.

Use a global catalog when | Advantage | Disadvantage
A commonly used application in the site utilizes port 3268 to resolve global catalog queries. | Performance improvement | Additional network traffic due to replication
A slow or unreliable WAN connection is used to connect to other sites. Use the same failure and load distribution rules that you used for individual domain controllers to determine whether additional global catalog servers are necessary in each site. | Fault tolerance | Additional network traffic due to replication
Users in the site belong to a Windows 2000 domain running in native mode. In this case, all users must obtain universal group membership information from a global catalog server. If a global catalog is not located within the same site all logon requests must be routed over your WAN connection to a global catalog located in another site. If a domain controller running Windows Server 2003 in the site has universal group membership caching enabled, then all users will obtain a current cached listing of their universal group memberships. | Fast user logons | Additional network traffic due to replication

Note

  • Network traffic related to global catalog queries generally use more network resources than normal directory replication traffic.

Universal group membership caching

Due to available network bandwidth and server hardware limitations, it may not be practical to have a global catalog in smaller branch office locations. For these sites, you can deploy domain controllers running Windows Server 2003, which can store universal group membership information locally.

Information is stored locally once this option is enabled and a user attempts to log on for the first time. The domain controller obtains the universal group membership for that user from a global catalog. Once the universal group membership information is obtained, it is cached on the domain controller for that site indefinitely and is periodically refreshed. The next time that user attempts to log on, the authenticating domain controller running Windows Server 2003 will obtain the universal group membership information from its local cache without the need to contact a global catalog.

By default, the universal group membership information contained in the cache of each domain controller will be refreshed every 8 hours. To refresh the cache, domain controllers running Windows Server 2003 will send a universal group membership confirmation request to a designated global catalog. Up to 500 universal group memberships can be updated at once. Universal group membership caching can be enabled using Active Directory Sites and Services. Universal group membership caching is site specific and requires that all domain controllers running Windows Server 2003 be located in that site to participate. For more information about how to enable this option, see To cache universal group memberships.

The following list summarizes potential benefits for caching universal group memberships in branch office locations:

  • Faster logon times since authenticating domain controllers no longer need to access a global catalog to obtain universal group membership information.
  • No need to upgrade hardware of existing domain controllers to handle the extra system requirements necessary for hosting a global catalog.
  • Minimized network bandwidth usage since a domain controller will not have to handle replication for all of the objects located in the forest.

Note

  • You might want to continue using a global catalog in branch office locations if an application in a site is sending global catalog queries to port 3268. Universal group membership caching does not intercept calls made to port 3268.


Interoperating with DNS and Group Policy

This section covers:

  • DNS integration
  • Group Policy integration


DNS integration

Active Directory is integrated with DNS in the following ways:

  • Active Directory and Domain Name System (DNS) have the same hierarchical structure.

    • Although separate and implemented differently for different purposes, an organization's namespace for DNS and Active Directory have an identical structure. For example, microsoft.com is a DNS domain and an Active Directory domain. For more information, see Namespace planning for DNS.

  • DNS zones can be stored in Active Directory.

    • If you are using the Windows Server 2003 DNS Server service, primary zone files can be stored in Active Directory for replication to other Active Directory domain controllers. For more information, see Active Directory integration.

  • Active Directory uses DNS as a locator service, resolving Active Directory domain, site, and service names to an IP address.

    • To log on to an Active Directory domain, an Active Directory client queries their configured DNS server for the IP address of the LDAP service running on a domain controller for a specified domain. For more information about how Active Directory clients rely on DNS, see Locating a domain controller.

Note

  • You can use Dcdiag.exe and Netdiag.exe to troubleshoot client computers that cannot locate a domain controller. These tools can help determine both server and client DNS misconfigurations. For more information, see article Q265706, "DCDiag/NetDiag Facilitate Join and DC Creation" in the Microsoft Knowledge Base. For a brief description of support tools, see Active Directory support tools.

While Active Directory is integrated with DNS and shares the same namespace structure, it is important to distinguish the difference between them:

  • DNS is a name resolution service.

    • DNS clients send DNS name queries to their configured DNS server. The DNS server receives the name query and either resolves the name query through locally stored files or consults another DNS server for resolution. DNS does not require Active Directory to function.

  • Active Directory is a directory service

    • Active Directory provides an information repository and services to make information available to users and applications. Active Directory clients send queries to domain controllers using the Lightweight Directory Access Protocol (LDAP). In order to locate a domain controller, an Active Directory client queries DNS. Active Directory requires DNS to function.

For a checklist on deploying DNS for Active Directory, see Checklist: Deploying DNS for Active Directory.

For information about configuring DNS servers for Active Directory, see To configure a DNS server for use with Active Directory.


Group Policy integration

Group Policy can be used to define default settings that will be automatically applied to user and computer accounts in Active Directory. Policy settings can be used to manage desktop appearance, assign scripts, redirect folders from local computers to network locations, determine security options and control what software can be installed on particular computers and what software is available to particular groups of users.

Here are a few examples of how Group Policy settings can be used in Active Directory:

  • Set the minimum password length and the maximum length of time that a password will remain valid. This can be configured for an entire domain.
  • Administrators can automatically install an application on every computer in a particular domain or on all computers assigned to a particular group in a particular site. For example, you could automatically install Microsoft Outlook on every computer in the domain and automatically install Microsoft Excel only on those computers belonging to the Accounting group in a particular site.
  • Logon, logoff, startup, and shutdown scripts can be assigned based on the locations of the computer and user accounts in Active Directory.
  • If members of a particular group often use different computers, administrators can install the necessary applications on each of those computers.
  • Any user's My Documents folder can be redirected to a network location. Users can then gain access to their documents from any computer on the network.

Policy settings are stored in Group Policy objects. Group Policy settings from more than one Group Policy object can be applied to a particular site, domain, or organizational unit. For example, if a site contains three domains, one Group Policy object could control computer configurations for the entire site. A separate policy for each domain could determine specific security settings for the computers in each domain. If each domain contains an Accounting and a Marketing organizational unit, additional Group Policy objects could determine what software is installed on the computers used by the Accounting and Marketing groups throughout the entire site.

This ability to automatically configure and secure computers throughout your organization by selectively applied Group Policy objects is a very powerful administrative tool. For more information about controlling software installation with Group Policy and how to create a Group Policy object, see Group Policy.

You can use security groups to filter how Group Policy settings are applied to collections of users and computers belonging to a particular site, domain, or organizational unit. For more information about security groups, see Group types. For general information about Group Policy, see Group Policy overview.


Understanding schema

This section covers:

  • Schema
  • Schema classes and attributes
  • Schema object names
  • Deactivating a class or attribute
  • Extending the schema


Schema

The Active Directory schema contains the definitions for all objects in the directory. Every new directory object you create is validated against the appropriate object definition in the schema before being written to the directory. The schema is made up of object classes and attributes. The base (or default) schema contains a rich set of object classes and attributes to meet the needs of most organizations, and is modeled after the International Standards Organization (ISO) X.500 standard for directory services. Because it is extensible, you can modify and add classes and attributes to the base schema. However, you should carefully consider each change you make, because extending the schema affects the entire network. For more information, see Extending the schema.

How directory objects are defined

In the schema, an object class represents a category of directory objects, such as users, printers, or application programs, that share a set of common characteristics. The definition for each object class contains a list of the schema attributes that can be used to describe instances of the class. For example, the User class has attributes such as givenName, surname, and streetAddress. When you create a new user in the directory the user becomes an instance of the User class, and the information you enter about the user becomes instances of the attributes. For more information, see Schema classes and attributes.

How the schema is stored

Each forest can contain only one schema, which is stored in the schema directory partition. The schema directory partition, along with the configuration directory partition, is replicated to all domain controllers in a forest. However, a single domain controller, the schema master, controls the structure and content of the schema. For more information about the schema master, see Operations master roles.

Schema cache

To improve performance on schema operations (such as new object validation), each domain controller holds a copy of the schema in memory (in addition to the copy it holds on disk). This cached version is automatically updated (after a small time interval) each time you update the schema. Or, you can reload the updated schema to cache manually for immediate effect. For more information, see To reload the schema.

Securing the schema

Like every object in Active Directory, schema objects are protected from unauthorized use by access control lists (ACLs). By default, only members of the Schema Admins group have write access to the schema. So, to extend the schema you must be a member of the Schema Admins group. The only default member of the Schema Admins group is the administrator account in the root domain of the forest. You should restrict membership in the Schema Admins group because extending the schema improperly can have serious consequences to your network. For more information, see Access control in Active Directory and Default groups.

For more information about the schema, see "Active Directory Schema" at the Microsoft Windows Resource Kits Web site (http://www.microsoft.com/) and at the Microsoft MSDN Web site.(http://msdn.microsoft.com/)


Schema classes and attributes

Every directory object you create is an instance of an object class contained in the schema. Each object class contains a list of associated attributes that determine the information the object can contain. Classes and attributes are defined independently, so that a single attribute can be associated with multiple classes. All schema classes and attributes are defined by the classSchema and attributeSchema objects, respectively.

Classes

ClassSchema objects are used to define classes in the schema. A classSchema object provides the template for building directory objects of that class. Examples of classSchema include User and Server. A classSchema object contains, among other things, the following information:

  • Class type (structural, abstract, or auxiliary)
  • Common name and Lightweight Directory Access Protocol (LDAP) display name
  • Lists of the "must contain" and "may contain" attributes for instances of the object
  • Relative distinguished name attribute
  • A list of possible parent classes

Class types

Three different types of classes exist in the schema:

Class type | Purpose
Structural | Used to instantiate objects (users, servers and so on) in the directory.
Abstract | Provides templates for deriving structural classes
Auxiliary | Contains predefined lists of attributes that can be included in structural and abstract classes.

Note

  • With the Windows Server 2003 family, the inetOrgPerson class is now a part of base schema. This class can be used as a security principal in the same manner as the user class.

Attributes

AttributeSchema objects are used to define attributes in the schema. An attributeSchema object determines the allowable contents and syntax for instances of that attribute in the directory. Examples of attributeSchema include User-Principal-Name and Telex-Number. An attributeSchema object contains, among other things, the following information:

  • Common name and LDAP display name
  • Syntax rules
  • Data constraints (single versus multivalued, minimum, and maximum values)
  • Whether and how the attribute is indexed

Single and multivalued attributes

Attributes can be single-valued or multivalued. An instance of a single-valued attribute can can only contain a single value. An instance of a multivalued attribute can contain multiple values of uniform syntax. A multivalued attribute stores no information about ordering of the attributes it contains. Each value of a multivalue attribute must be unique.

Indexed attributes

Both multivalued and single valued attributes can be indexed to help improve the performance of queries on that attribute. (Indexing does not apply to classes.) Attributes are marked for indexing based on their schema definition. Indexing an attribute also allows users to use wildcards (*) as prefixes and suffixes when specifying a search string. When you mark an attribute as indexed, all instances of the attribute are added to the index, not just the instances that are members of a particular class. Indexing attributes, particularly multivalued attributes, can negatively affect replication and object creation time, as well as directory database size. So, it is recommended that you only index commonly used attributes. For more information, see To index an attribute in Active Directory.

For more information about the schema, see "Active Directory Schema" at the Microsoft Windows Resource Kits Web site (http://www.microsoft.com/) and the Microsoft MSDN Web site. (http://www.microsoft.com/)


Schema object names

When extending the schema, you need to know how to reference schema objects. Both class and attribute schema objects can be referenced in several ways:

  • Lightweight Directory Access Protocol (LDAP) display name
  • common name
  • object identifier

LDAP display name

The Active Directory Schema snap-in and other administrative tools display the LDAP display name of objects. Programmers and system administrators use LDAP display names to reference objects programmatically. The LDAP display name typically consists of two or more words combined. When the name consists of multiple words, subsequent words in the name are identified using capitalization. Example LDAP display names are mailAddress and machinePasswordChangeInterval. The LDAP display name is guaranteed to be unique for each object.

Common name

The common name is a more readable version of the LDAP display name. The common names of the two attributes used in the previous example are SMTP-Mail-Address and Machine-Password-Change-Interval. Common names are guaranteed to be unique within a container.

Object identifier

An object identifier (also known as OID) is issued by an issuing authority such as the International Organization for Standardization (ISO) or the American National Standards Institute (ANSI). For example, the object identifier for the SMTP-Mail-Address attribute is 1.2.840.113556.1.4.786. Every object identifier must be unique. For more information about ISO, see the International Organization for Standardization Web site.

When extending your schema, you can register new object identifiers through Microsoft. For more information, see the Microsoft Web site.(http://www.microsoft.com/)

Schema object naming rules

To help standardize schema naming conventions, Microsoft strongly suggests that schema extensions adhere to naming rules for both the LDAP Display Name and the Common Name. To qualify as "Certified for Windows," an application that extends the schema must adhere to these naming rules. For more information, see the Active Directory chapter of the certification program documentation at the Microsoft Web site (http://www.microsoft.com/). See also the Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).

Message queuing aliases

A message queuing alias is an object in Active Directory that can be used to reference queues which might not be listed in Active Directory. For example, a queuing alias can be used to reference a private queue within the context of a distribution list. You can create a queuing alias by using Active Directory Users and Computers. Using queuing aliases provides the following benefits:

  • When a queuing alias object is deleted, the alias is automatically removed from all distribution lists that reference the alias.
  • A queue referenced by a queuing alias can be changed without changing the alias.
  • Queuing aliases can be used to reference a queue not listed in the directory service, including private queues or queues from another organization.
  • Queuing aliases can be used to send http messages by referencing the destination queue using a direct format name.

A queuing alias object has a single attribute, a format name that references a queue. Queuing aliases can contain public, private, and direct format names. The format name for the queue cannot exceed 255 characters. For more information, see Using Message Queuing.

Note

  • XOX


Deactivating a class or attribute

Domain controllers running Windows Server 2003 do not permit the deletion of classes or attributes, but they can be deactivated if they are no longer needed or if there was an error in the original definition. A deactivated class or attribute is considered defunct. A defunct class or attribute is unavailable for use; however, it is easily reactivated.

If your forest has been raised to the Windows Server 2003 functional level, you can reuse the object identifier (governsId and attributeId values), the ldapDisplayName, and the schemaIdGUID that were associated with the defunct class or attribute. This allows you to change the object identifier associated with a particular class or attribute. The only exception to this is that an attribute used as a rdnAttId of a class continues to own its attributeId, ldapDisplayName, and schemaIdGuid values even after being deactivated (for example, those values cannot be reused).

If your forest has been raised to the Windows Server 2003 functional level, you can deactivate a class or attribute and then redefine it. For example, the Unicode String syntax of an attribute called SalesManager could be changed to Distinguished Name. Since Active Directory does not permit you to change the syntax of an attribute after it has been defined in the schema, you can deactivate the SalesManager attribute and create a new SalesManager attribute that reuses the same object identifier and LDAP display name as the old attribute, but with the desired attribute syntax. You must rename the deactivated attribute before it can be redefined.

For more information about forest functionality, see Domain and forest functionality.

Notes

  • Classes and attributes added to the base schema can be deactivated without raising the forest functional level. However, they can be redefined only in forests raised to the Windows Server 2003 functional level or higher.
  • Default schema attributes or classes in the base schema cannot be deactivated if bit 4 of the systemFlags attribute is set to 1. Only attributes or classes where bit 4 of the systemFlags attribute is equal to zero can be deactivated.

Object identifiers must be unique. Mistyping a number when entering an object identifier can cause a conflict between the invalid object identifier and a legitimate object identifier that is registered by an application. When installing an application that adds an attribute or class, the application may need to use the mistyped object identifier for one of its legitimate schema extensions. You can correct object identifier conflicts in forests that are set to the Windows Server 2003 functional level. To correct the conflict, deactivate the attribute or class with the incorrect object identifier. The application installation program will then be able to create the new attribute or class using the correct object identifier.

Before deactivating a class, consider the following:

  • You can deactivate a class only if that class is not specified as a subClassOf, auxiliaryClass, systemAuxiliaryClass, possSuperiors, or systemPossSuperiors of any existing active class.
  • You cannot use a defunct class in definitions of new classes, and you cannot add it to existing class definitions.
  • You cannot create objects that are instances of the defunct class or modify existing instances of the class. However, the instances of the defunct class become available again for modification when the defunct class is reactivated.

Before deactivating an attribute, consider the following:

  • You can deactivate an attribute only if the attribute is not specified as a systemMustContain, mustContain, systemMayContain, mayContain, or rdnAttId of any existing active class.
  • You cannot use a defunct attribute in definitions of new classes, and you cannot add it to existing class definitions.
  • You cannot read, modify, or delete instances of the defunct attribute present in existing objects. However, the instances of the defunct attribute become available when the defunct attribute is reactivated.
  • To purge the directory of instances of an attribute you must delete the instances before deactivating the attribute.

Classes and attributes can be deactivated programmatically (recommended) or by using the Active Directory Schema snap-in. To deactivate a class or attribute using the Active Directory Schema snap-in, see To deactivate a class or attribute. For information about programmatically deactivating classes and attributes, see the Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).

Reactivating a class

A defunct class can be reactivated. However, a defunct class cannot be reactivated unless the attributes referenced in its mustContain, systemMustContain, mayContain, and systemMayContain properties are active and the classes referenced in its subClassOf, auxiliaryClass, systemAuxiliaryClass, possSuperiors, and systemPossibleSuperiors properties are also active.

Further, a defunct class cannot be reactivated if the values of the following attributes collide with an already active attribute or class: ldapDisplayName, attributeId, governsId, or schemaIdGuid.

To reactive a defunct class, see To reactivate a class or attribute.

Reactivating an attribute

An defunct attribute can be reactivated. However, a defunct attribute cannot be reactivated if the values of the following attributes collide with an already active attribute or class: ldapDisplayName, attributeId, governsId, schemaIdGuid, or mapiId.

To reactive a defunct attribute, see To reactivate a class or attribute.


Extending the schema

When the set of classes and attributes in the base Active Directory schema do not meet your needs, you can extend the schema by modifying or adding classes and attributes. You should only extend the schema when absolutely necessary. The easiest way to extend the schema is through the Schema Microsoft Management Console (MMC) snap-in. You should always develop and test your schema extensions in a test lab before moving them to your production network.

Before extending the schema

Before extending the schema, review these key points:

Check the base schema first | Verify that no existing class or attribute in the base schema meets your application or data needs. For the complete set of classes and attributes in the base schema, see the Microsoft Web site (http://www.microsoft.com/).
Review schema documentation | For detailed information about extending the schema, see the Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/) and "Active Directory Schema" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
Schema modifications are global | When you extend the schema, the changes apply to every domain controller in the entire forest.
Schema classes related to the system cannot be modified | You cannot modify default system classes (those classes required for Windows to run) within the schema. However, directory-enabled applications that modify the schema may add new classes that you can modify.
Schema extensions are not reversible | Attributes or classes cannot be removed after creation. At best, they can be modified or deactivated. For more information, see Deactivating a class or attribute.
Obtain valid object identifiers | Every class and attribute in the schema must have a unique and valid object identifier (also known as OID). Do not create arbitrary object identifiers or recycle old object identifiers. For information about obtaining valid object identifiers, see Schema object names.
Document your changes | If you do decide to extend the schema, be sure to document your changes.

How to extend the schema

You can modify the schema through graphical user interface (GUI) tools, command-line tools, and through scripting. The easiest way to modify the schema is by using the Active Directory Schema snap-in in Microsoft Management Console (MMC), which is a GUI tool for schema management. For information about installing the Active Directory Schema snap-in, see To install the Active Directory Schema snap-in. Modifying the schema through scripting requires programming knowledge and familiarity with the Active Directory Service Interfaces (ADSI). For more information, see the Active Directory Programmer's Guide (http://www.microsoft.com/) and Extending the Schema at the Microsoft MSDN Web site.(http://www.microsoft.com/)

For more information about schema administration tools, see Administration tools for the Active Directory schema.

For more information about extending the schema, see To modify an existing schema class or attribute definition and To add a new schema class or attribute definition. For information about deactivation and reactivation, see Deactivating a class or attribute, To deactivate a class or attribute and To reactivate a class or attribute.

Using a test forest

A very simple way to avoid damaging or costly schema mistakes in your production forest is to first test your schema extensions on a test forest. By using a test environment, you can identify any potential problems in your plan before they affect your users and your production environment.

After making schema changes in a test forest, you can reinstall the default schema by demoting each domain controller in the test forest to which the schema changes have replicated. Then, use the Active Directory Installation Wizard to reinstall Active Directory on the servers. This procedure is practical only in a test environment.


Deploying Active Directory

This section covers:

  • Deployment resources
  • Using the Active Directory Installation Wizard
  • Creating an additional domain controller
  • Creating a new domain tree
  • Creating a new child domain
  • Creating a new forest
  • Upgrading from Windows NT or Windows 2000


Deployment resources

To deploy domain controllers running Windows Server 2003, it is recommended that you use the Microsoft Windows Server 2003 Deployment Kit, which is available online at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

The online deployment kit includes case studies and the necessary information for deploying Windows Server 2003 Active Directory in networks that have domain controllers running Windows NT 4.0 or Windows 2000. For complete information, see "Upgrading Windows NT 4.0 Domains to Windows Server 2003" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

If your network includes branch offices, see "Designing the Site Topology" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/) This online guide helps plan Active Directory deployment when there are branch office sites connected with slow network links.

For information about monitoring Active Directory, see "Monitoring Active Directory" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Using the Active Directory Installation Wizard

The Active Directory Installation Wizard installs and configures domain controllers, which provide network users and computers access to the Active Directory directory service. You can install Active Directory on any member server (except those with restrictive license agreements) using the Active Directory Installation Wizard. Using the wizard, you will define one of the following roles for the new domain controller:

  • New forest (also a new domain)

    • For a checklist about creating a new forest, see Checklist: Creating a new forest.

  • New child domain

    • For a checklist about creating a child domain, see Checklist: Creating a new child domain.

  • New domain tree in an existing forest

    • For a checklist about creating a new domain tree, see Checklist: Creating a new domain tree.

  • An additional domain controller in an existing domain.

    • For a checklist about creating an additional domain controller, see Checklist: Creating an additional domain controller in an existing domain.

Before using the Active Directory Installation Wizard, consider DNS configuration and support for existing applications.

DNS configuration

By default, the Active Directory Installation Wizard attempts to locate an authoritative DNS server for the new domain from its list of configured DNS servers that will accept a dynamic update of a service (SRV) resource record. If found, all the appropriate records for the domain controller are automatically registered with the DNS server after the domain controller is restarted.

If a DNS server that can accept dynamic updates is not found, either because the DNS server does not support dynamic updates or dynamic updates are not enabled for the domain, then the Active Directory Installation Wizard will take the following steps to ensure that the installation process is completed with the necessary registration of the SRV resource records:

  1. The DNS service is installed on the domain controller and is automatically configured with a zone based on the Active Directory domain.

    2. For example, if the domain that you chose for your first domain in the forest is example.microsoft.com, then a zone rooted at the DNS domain name of example.microsoft.com is added and configured to use the DNS Server service on the new domain controller.

  2. A text file containing the appropriate DNS resource records for the domain controller is created.

    3. The file called Netlogon.dns is created in the systemroot\System32\Config folder and contains all the records needed to register the resource records of the domain controller. Netlogon.dns is used by the Net Logon service and supports Active Directory on servers running non-Windows Server 2003 DNS.

    If you are using a DNS server that supports the SRV resource record but does not support dynamic updates (such as a UNIX-based DNS server or a Windows NT DNS server), you can import the records in Netlogon.dns into the appropriate primary zone file to manually configure the primary zone on that server to support Active Directory.

If no DNS servers are available on the network, you can choose the option to automatically install and configure a local DNS server when you install Active Directory using the Active Directory Installation Wizard. The DNS server will be installed on the server on which you are running the wizard, and the server's preferred DNS server setting will be configured to use the new local DNS server.

Before running the Active Directory Installation Wizard, ensure that the authoritative DNS zone allows dynamic updates and that the DNS server hosting the zone supports the DNS SRV resource record. For more information, see Checklist: Verifying DNS before installing Active Directory.

For more information, see To configure a DNS server for use with Active Directory. For general information about DNS integration with Active Directory, see DNS integration.

Support for existing applications

On servers running Windows NT 4.0 and earlier, read access for user and group information is assigned to anonymous users so that existing applications and some non-Microsoft applications function correctly.

On servers running Windows 2000 and Windows Server 2003, members of the Anonymous Logon group have read access to this information only when the group is added to the Pre-Windows 2000 Compatible Access group.

Using the Active Directory Installation Wizard, you can choose if you want the Anonymous Logon group and the Everyone security groups to be added to the Pre-Windows 2000 Compatible Access group by selecting the Permissions compatible with pre-Windows 2000 server operating systems option. To prevent members of the Anonymous Logon group from gaining read access to user and group information, choose the Permissions compatible only with Windows Server 2003 operating systems option.

When upgrading a domain controller from Windows 2000 to a Windows Server 2003 operating system, if the Everyone security group is already a member of the pre-Windows 2000 Compatible Access security group (indicating backward compatibility settings), the Anonymous Logon security group will be added as a member of the pre-Windows 2000 Compatible Access security group during the upgrade.

You can manually switch between the backward compatible and high-security settings on Active Directory objects by adding the Anonymous Logon security group to the pre-Windows 2000 Compatible Access security group using Active Directory Users and Computers. For more information about adding members to a group, see To add a member to a group. For more information about default groups, see Default groups and Special identities.

Note

  • If you select the Permissions compatible only with Windows Server 2003 operating systems check box when installing Active Directory and find that your applications are not functioning correctly, try resolving the problem by manually adding the special group Everyone to the Pre-Windows 2000 Compatible Access security group, and then restarting the domain controllers in the domain. Once you have upgraded to applications compatible with the Windows Server 2003 family, you should return to the more secure Windows Server 2003 operating system configuration by removing the Everyone group from the Pre-Windows 2000 Compatible Access security group and restarting the domain controllers in the affected domain.


Creating additional domain controllers

If you already have one domain controller in a domain, you can add additional domain controllers to the domain to improve the availability and reliability of network services. Adding additional domain controllers can help provide fault tolerance, balance the load of existing domain controllers, and provide additional infrastructure support to sites.

More than one domain controller in a domain makes it possible for the domain to continue to function if a domain controller fails or must be disconnected. Multiple domain controllers can also improve performance by making it easier for clients to connect to a domain controller when logging on to the network. You can add additional domain controllers over the network or from backup media.

Before adding domain controllers you should thoroughly understand Active Directory and the requirements necessary to set up additional domain controllers in an existing domain. For more information, see Checklist: Creating an additional domain controller in an existing domain and To create an additional domain controller.

Using backup media to create additional domain controllers

With Windows 2000, the only way you can create an additional domain controller in an existing domain is by replicating the entire directory database to the new domain controller. With low network bandwidth or a large directory database, this replication can take hours or days to complete. With servers running Windows Server 2003, you can create an additional domain controller using a restored backup taken from a domain controller running Windows Server 2003. This backup can be stored on any backup media (tape, CD, or DVD) or a shared resource.

Using restored backup files to create an additional domain controller will greatly reduce the network bandwidth used when installing Active Directory over a shared resource; however, network connectivity is still necessary so that all new objects and recent changes to existing objects are replicated to the new domain controller.

It is recommended that you use the most recent backup available. Older backups require more network bandwidth for replication. The backup used cannot be older than the tombstone lifetime of the domain, which is set to a default value of 60 days.

If a domain controller that was backed up contained an application directory partition, it will not be restored on the new domain controller. To manually create an application directory partition on a new domain controller, see To create or delete an application directory partition.

When adding an additional domain controller using backup media, a System State backup taken only from a domain controllers running Windows Server 2003 can be used once it has been restored. For more information about how to restore a System State backup, see To restore System State data.

For general information about restoring backups, see Authoritative, primary, and normal restores.


Creating a new domain tree

Create a new domain tree only when you need to create a domain whose DNS namespace is not related to the other domains in the forest. This means that the name of the tree root domain (and all of its children) does not have to contain the full name of the parent domain. A forest can contain one or more domain trees. For information about how to create a new domain tree, see To create a new domain tree.

Before creating a new domain tree, consider creating another forest when you want a different DNS namespace. Multiple forests provide administrative autonomy, isolation of the schema and configuration directory partitions, separate security boundaries, and the flexibility to use an independent namespace design for each forest. For more information, see Creating a new forest.


Creating a new child domain

Create a new child domain when you want to create a domain that shares a contiguous namespace with one or more domains. This means that the name of the new domain contains the full name of the parent domain. For example, sales.microsoft.com would be a child domain of microsoft.com. As a best practice, you create new domains as children of the forest root domain.

You can create a new child domain by creating a new domain under a parent domain using the Active Directory Installation Wizard. For information about how to create a new child domain, see To create a new child domain.

After you create the child domain, you can create additional domain controllers in the child domain for fault tolerance and high availability of Active Directory. For more information, see Creating additional domain controllers.


Creating a new forest

When you create the first domain controller in your organization, you are creating the first domain (also called the forest root domain) and the first forest.

The top-level Active Directory container is called a forest. A forest consists of one or more domains that share a common schema and global catalog. An organization can have multiple forests.

A forest is the security and administrative boundary for all objects that reside within the forest. In contrast, a domain is the administrative boundary for managing objects, such as users, groups, and computers. In addition, each domain has individual security policies and trust relationships with other domains.

Multiple domain trees within a single forest do not form a contiguous namespace; that is, they have noncontiguous DNS domain names. Although trees in a forest do not share a namespace, a forest does have a single root domain, called the forest root domain. The forest root domain is, by definition, the first domain created in the forest. The Enterprise Admins and Schema Admins groups are located in this domain. By default, members of these two groups have forest-wide administrative credentials.

When to create a new forest

A first step in the Active Directory design process is to determine how many forests your organization needs. For most organizations, a single forest design is the preferred model and the simplest to administer. However, a single forest may not be practical for every organization.

With a single forest, users do not need to be aware of directory structure because all users see a single directory through the global catalog. When adding a new domain to a forest, no additional trust configuration is required because all domains in a forest are connected by two-way, transitive trusts. In a forest with multiple domains, configuration changes need be applied only once to update all domains.

However, there are scenarios in which you might want to create more than one forest:

  • When upgrading a Windows NT domain to a Windows Server 2003 forest. You can upgrade a Windows NT domain to become the first domain in a new Windows Server 2003 forest. To do this, you must first upgrade the primary domain controller in that domain. Then, you can upgrade backup domain controllers, member servers, and client computers at any time.

    You can also keep a Windows NT domain and create a new Windows Server 2003 forest by installing Active Directory on a member server running Windows Server 2003. For more information, see Upgrading from a Windows NT domain.

  • To provide administrative autonomy. You can create a new forest when you need to segment your network for purposes of administrative autonomy. Administrators who currently manage the IT infrastructure for autonomous divisions within the organization may want to assume the role of forest owner and proceed with their own forest design. However, in other situations, potential forest owners may choose to merge their autonomous divisions into a single forest to reduce the cost of designing and operating their own Active Directory or to facilitate resource sharing. For more information, see "Best Practice Active Directory Design for Managing Windows Networks" at the Microsoft Web site. (http://www.microsoft.com/)
  • To create a different Domain Name System (DNS) namespace than an existing forest. You can create a new forest when you need to use a noncontiguous DNS namespace that is different from an existing forest on your network. It is recommended that you create a new forest when you want a different DNS namespace rather than creating additional domain trees with noncontiguous DNS namespaces within an existing forest. For more information, see "Best Practice Active Directory Design for Managing Windows Networks" at the Microsoft Web site. (http://www.microsoft.com/)

Operations master roles in a new forest

When you create the first forest in your organization, all five operations master roles are automatically assigned to the first domain controller in the forest. As new child domains are added to the forest, the first domain controller in each of the new child domains is automatically assigned the following roles:

  • Relative identifier master
  • Primary domain controller (PDC) emulator
  • Infrastructure master

Because there can be only one schema master and one domain naming master in a forest, these roles remain in the forest root domain. In an Active Directory forest with only one domain and one domain controller, that domain controller owns all the operations master roles. For more information, see Operations master roles.

Adding new domains to your forest

A domain stores only the information about objects located in that domain, so by creating multiple domains within a new forest, you are partitioning or segmenting Active Directory to better serve a disparate user base.

The easiest domain structure to administer is a single domain within a single forest. When planning, you should start with a single domain and only add additional domains when the single domain model no longer meets your needs. For more information about creating domains, see Domains.

Before creating a new forest

Active Directory requires DNS to function and both share the same hierarchical domain structure. For example, microsoft.com is a DNS domain and an Active Directory domain. Because of the reliance that Active Directory has on DNS you must thoroughly understand Active Directory and DNS concepts before creating a new forest. For more information, see Checklist: Creating a new forest.


Upgrading from Windows NT or Windows 2000

This section covers:

  • Upgrading overview
  • Upgrading from a Windows NT domain
  • Upgrading from a Windows 2000 domain
  • Converting groups


Upgrading overview

The Active Directory® directory service is compatible with Microsoft® Windows NT® and supports a mix of operations that support domain controllers running Windows NT 4.0, Windows® 2000, and Windows Server 2003. This allows you to upgrade domains and computers at your own pace, based on your organization's needs.

Active Directory supports the NTLM protocol used by Windows NT. This enables authorized users and computers from a Windows NT domain to log on and access resources in Windows 2000 or Windows Server 2003 domains. To clients running Windows 95, Windows 98, or Windows NT that are not running Active Directory client software, a Windows 2000 or Windows Server 2003 domain appears to be a Windows NT 4.0 domain. For more information, see Active Directory clients.

The upgrade to Active Directory can be gradual and performed without interrupting operations. If you follow domain upgrade recommendations, it should never be necessary to take a domain offline to upgrade domain controllers, member servers, or workstations. When upgrading a Windows NT domain, you must upgrade the primary domain controller first. You can upgrade member servers and workstations at any time after this. For more information, see Upgrading from a Windows NT domain.

Active Directory allows upgrading from any Windows NT 4.0 domain model and supports both centralized and decentralized models. The typical master or multiple-master domain model can be easily upgraded to an Active Directory forest.


Upgrading from a Windows NT domain

See the following recommended steps for upgrading from a Windows NT domain.

Plan and implement a namespace and DNS infrastructure

Because Domain Name System (DNS) is required for Active Directory, ensure that you have designed a DNS and Active Directory namespace and have either configured DNS servers or are planning to use the Active Directory Installation Wizard to automatically install the DNS service. For more information, see DNS integration and Namespace planning for DNS.

Determine forest functionality

Forest functionality determines the type of Active Directory features that can be enabled within the scope of a single forest. Each forest functional level has a set of specific minimum requirements for the versions of operating systems that domain controllers throughout the forest can run. For example, the Windows Server 2003 forest functional level requires that all domain controllers run a product in the Windows Server 2003 family.

When you are upgrading your first Windows NT domain to become the first Windows Server 2003 domain, it is recommended that you set the forest functional level to the Windows Server 2003 interim forest functional level, which you will be prompted to set during the upgrade. This level contains all of the features used in the Windows 2000 forest functional level, including the following two important Active Directory replication enhancements:

  • Improved replication efficiency and scalability. For more information, see Replication overview.
  • Linked value replication for more efficient replication of group memberships. For more information, see How replication works.

For more information, see New features for Active Directory.

The Windows Server 2003 interim functional level is an option only when upgrading the first Windows NT domain to a new forest and can be manually configured after the upgrade. For more information about how to manually set this functional level, see "Upgrading Windows NT 4.0 Domains to Windows Server 2003" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/) The Windows Server 2003 interim forest functional level only supports domain controllers running Windows Server 2003 and Windows NT, not domain controllers running Windows 2000. You cannot install Active Directory on servers running Windows 2000 in a forest with the functional level set to Windows Server 2003 interim. For more information about forest functionality, see Domain and forest functionality.

Upgrade the primary domain controller

The first server you must upgrade is the primary domain controller (PDC) running Windows NT 4.0 or earlier. During the upgrade, the Active Directory Installation Wizard requires that you choose to join an existing domain tree or forest or create a new domain tree or forest. If you decide to join an existing domain tree, you must provide a reference to the desired parent domain. For more information, see Checklist: Creating a new forest, Checklist: Creating a new child domain, or Checklist: Creating a new domain tree.

The Active Directory Installation Wizard installs all the necessary components on the domain controller, such as the directory data store and the Kerberos V5 protocol authentication software. Once the Kerberos V5 protocol is installed, the installation process starts the authentication service and the ticket granting service.

If this is a new child domain, then a transitive trust relationship is established with the parent domain. Eventually, the domain controller from the parent domain copies all schema and configuration information to the new child domain controller. The existing Security Accounts Manager (SAM) objects will be copied from the registry to the new data store. These objects are security principals.

During the upgrade, container objects are created to contain the accounts and groups from the Windows NT domain. The container objects are named Users, Computers, and Builtin and are displayed as folders in Active Directory Users and Computers. User accounts and predefined groups are routed to the Users container. Computer accounts are routed to the Computers container. Built-in groups are routed to the Builtin container.

Existing Windows NT 4.0 and earlier groups are located in different folders depending on the nature of the group. Windows NT 4.0 and earlier built-in local groups (such as Administrators and Server Operators) are located in the Builtin container. Windows NT 4.0 and earlier global groups (such as Domain Admins), any user-created local groups, and global groups are located in the Users container.

The upgraded PDC can synchronize security principal changes to remaining backup domain controllers (BDCs) running Windows NT 4.0 or earlier. The upgraded PDC is recognized as the domain master by BDCs running Windows NT Server 4.0 or earlier.

The upgraded domain controller is a fully functional member of the forest. The new domain is added to the domain and site structure and all domain controllers receive the notification that a new domain has joined the forest.

Upgrade any remaining backup domain controllers

Once you have upgraded the PDC running Windows NT 4.0 or earlier, you can proceed to upgrade all remaining BDCs. During the upgrade process, you might want to remove one BDC from the network to guarantee a backup if any problems develop. This BDC will store a secure copy of your current domain database.

If any problems arise during the upgrade, you can remove all domain controllers running Windows Server 2003 from the production environment, and then bring the BDC back into your network and make it the new PDC. This new PDC will then replicate its data throughout the domain so that the domain is returned to its previous state.

The only drawback to this method is that all changes that were made while the safe BDC was offline are lost. To minimize this loss, you could periodically turn the safe BDC on and off again (when the domain is in a stable state) during the upgrade process to update its safe copy of the directory.

If a domain controller running Windows Server 2003 becomes unavailable and no other domain controllers running Windows Server 2003 exist in the domain, a BDC running Windows NT can be promoted to a PDC to fill the role for the offline domain controller running Windows Server 2003.

When upgrading Windows NT 4.0 and earlier domains, only one domain controller running Windows Server 2003 can create security principals (users, groups, and computer accounts). This single domain controller is configured as a PDC emulator master. The PDC emulator master emulates a Windows NT 4.0 or earlier PDC. For more information about the PDC emulator role, see Operations master roles.

Complete the upgrade of the domain

After you have upgraded all existing Windows NT 4.0 and earlier primary and backup domain controllers to a Windows Server 2003 operating system, and you have no plans to use Windows NT 4.0 and earlier domain controllers, you can raise the domain functional level from Windows 2000 mixed to Windows 2000 native. For more information about how to raise the domain functional level, see To raise the domain functional level.

Several things happen when you raise the domain functional level to Windows 2000 native:

  • Domain controllers no longer support NTLM replication.
  • The domain controller that is emulating the PDC operations master cannot synchronize data with a BDC running Windows NT 4.0 or earlier.
  • Domain controllers running Windows NT 4.0 and earlier cannot be added to the domain. You can add new domain controllers running Windows 2000 or Windows Server 2003.
  • Users and computers using previous versions of Windows begin to benefit from the transitive trusts of Active Directory and can access resources anywhere in the forest with the appropriate permissions. Although previous versions of Windows do not support the Kerberos V5 protocol, the pass-through authentication provided by the domain controllers allows users and computers to be authenticated in any domain in the forest. This enables users or computers to access resources in any domain in the forest for which they have the appropriate permissions.

Other than the enhanced access to any other domains in the forest, clients will not be aware of any changes in the domain.

After upgrading a Windows NT 4.0 domain to an Active Directory domain, it is recommended that you delete and recreate all previously existing trusts with Active Directory domains. Even though the domain has been upgraded, the trust remains a Windows NT 4.0 trust. Internet Protocol security (IPSec) does not work over a Windows NT 4.0 trust.

Install Active Directory client software on older client computers

Computers running Active Directory client software can use Active Directory features, such as authentication, to access resources in the domain tree or forest and to query the directory. By default, client computers running Windows 2000 Professional and XOX have the client software built in and can access Active Directory resources normally.

Computers running previous versions of Windows (Windows 95, Windows 98, and Windows NT) require installation of the Active Directory client software before access to Active Directory resources is available. Without the client software, previous versions of Windows can only access the domain as if it were a Windows NT 4.0 and earlier domain, finding only those resources available through Windows NT 4.0 and earlier one-way trusts. For more information about the Active Directory client software, see Active Directory clients.


Upgrading from a Windows 2000 domain

Before upgrading a domain controller running Windows 2000 to Windows Server 2003, or installing Active Directory on the first domain controller running Windows Server 2003, ensure that your server, your forest, and your domain are ready. This process involves checking the upgrade compatibility of your server, preparing the forest, and preparing the domain, all of which can be accomplished using command-line tools.

To check the upgrade compatibility of the server and to copy any updated Setup files, run the winnt32 command, using the winnt32 /checkupgradeonly command. For more information about the Winnt32 command, see Winnt32.

To prepare the forest, run the adprep command on the schema operations master, using the adprep /forestprep command. Running adprep on the schema master will update the schema, which will in turn replicate to all of the other domain controllers in the forest. The time it takes to replicate these changes will vary, depending on the replication schedule for your organization.

After the changes made by adprep /forestprep have replicated to the infrastructure operations master, you are ready to prepare the domain. To prepare the domain, run adprep on the infrastructure operations master, this time using the adprep /domainprep command.

The Adprep command-line tool is available from the I386 directory on the operating system installation CD. For information about how to upgrade a Windows 2000 domain, see To prepare for upgrades in a domain containing Windows 2000 domain controllers.

Important

  • You cannot upgrade domain controllers running Windows 2000 to Windows Server 2003, or add domain controllers running Windows Server 2003 to Windows 2000 domains, until you have used adprep to prepare the forest and the domains within the forest.

For more information about operation master roles, see Operations master roles.


Converting groups

When you upgrade a primary domain controller (PDC) running Windows NT Server 4.0 or earlier to a server running Windows Server 2003, existing Windows NT groups are converted in the following ways:

  • Windows NT local groups are converted to domain local groups on servers running Windows Server 2003.
  • Windows NT global groups are converted to global groups on servers running Windows Server 2003.

Domain member computers running Windows NT can continue to display and access the converted groups. The groups appear to these clients as Windows NT 4.0 local and global groups. However, a Windows NT client cannot display members of groups or modify the member properties when that membership violates Windows NT group rules. For example, when a Windows NT client views the members of a global group on a server running Windows Server 2003, it does not view any other groups that are members of that global group.

Converted groups and Microsoft Exchange

Exchange allows users to arrange e-mail addresses in groups and distribution lists. When Exchange servers are upgraded to Active Directory, the Exchange distribution lists are converted to distribution groups with universal scope. The administrator can convert the group to a security group later, if desired, by using Active Directory Users and Computers to change the group properties. The messaging application programming interface (MAPI) enables computers running previous version Exchange clients to view the converted distribution group.

Using converted groups with servers running Windows Server 2003

Client computers that do not run Active Directory client software identify groups with universal scope on servers running Windows Server 2003 as having global scope instead. When viewing the members of a group with universal scope, the Windows NT client can only view and access group members that conform to the membership rules of global groups on servers running Windows Server 2003.

In a Windows Server 2003 domain that is set to a domain functional level of Windows 2000 native, all the domain controllers must be running on servers running Windows Server 2003. However, the domain can contain member servers that run Windows NT Server 4.0. These servers view groups with universal scope as having global scope and can assign groups with universal scope rights and permissions and place them in local groups.

In a Windows Server 2003 domain, a Windows NT Server 4.0 member server running Windows NT administrative tools cannot access domain local groups. However, you can work around this by using a server running Windows Server 2003 and using its Windows Server 2003 Administration Tools Pack to access the server running Windows NT Server 4.0. You can use the Administration Tools Pack to display the domain local groups and assign to them permissions to resources on the server running Windows NT Server 4.0.


Administering Active Directory

This section covers:

  • Using Run as
  • Using saved queries
  • Managing Active Directory from MMC
  • Managing Active Directory from the command line
  • Finding directory information
  • Administering other domains
  • Delegating administration
  • Publishing resources
  • Managing COM+ partitions in Active Directory
  • Managing COM+ partition sets in Active Directory


Using Run as

Logging onto your computer using administrative credentials can pose a security risk to your computer and network. Therefore, as a security best practice, it is recommended that you do not log on to your computer with administrative credentials. Instead, you can use Run as to accomplish administrative tasks without having to log on to your computer with administrative credentials. For information about the security risks associated with being logged on as an administrator, see Why you should not run your computer as an administrator.

Using Run as, you can open and run a program using a different account and security context than the one you are logged on with. So, you can log on using a regular user account, then, using Run as, open an administrative program in the context of an administrative account. The administrative context is only used for that specific program and is only available until that program is closed.

It is especially important for domain administrators to use Run as to accomplish administrative tasks. Running your computer as a domain administrator in Active Directory makes your domain (and forest) vulnerable to Trojan horses and other security risks that target the logon sequence.

You can use Run as through the user interface or as a command-line tool.

  • User interface

    • The Run as feature built into the user interface is a shortcut that is accessed on the right-click menu for some programs (.exe), some Control Panel (.cpl) items, and Microsoft Management Console (MMC) (.msc) consoles. Run as will prompt you for a user account and password before starting a program, Control Panel item, or MMC console. Some programs and administrative tasks, such as upgrading the operating system or configuring system parameters, do not support Run as. These tasks require an interactive logon. For more information about how to use the Run as feature, see To run a program with administrative credentials.

  • Command-line tool

    • In addition to the built-in Run as feature, the runas command provides the same capabilities. For more information about the runas command, see Runas. You can also create a custom shortcut using the runas command. For more information about creating shortcuts, see To create a shortcut using the runas command.


Using saved queries

Saved queries provide a quick and consistent way for administrators to access a common set of directory objects on which to perform specific tasks or to monitor. Saved queries use predefined LDAP strings to search only the specified domain partition, and searches can be narrowed down to a single container object. You can also create a customized saved query that contains a LDAP search filter. For more information about saving queries, see To create a saved query. For more information about LDAP search filters, see the Internet Engineering Task Force Web site and search for "Representation of LDAP Search Filters."

Active Directory Users and Computers provides a Saved Queries folder in which administrators can create, edit, save, and organize saved queries. Before saved queries, administrators were required to create custom ADSI scripts that would perform a query on common objects. This was an often lengthy process that required knowledge of how ADSI utilizes LDAP search filters to resolve a query.

All queries located in the Saved Queries folder are stored in Active Directory Users and Computers (dsa.msc). Once you have successfully created your customized set of queries you can copy the .msc file to other domain controllers running Windows Server 2003 (located in the same domain) and use the same set of saved queries. You can also export saved queries to an .xml file and import them into other Active Directory User and Computer consoles located on domain controllers running Windows Server 2003 (within the same domain). For more information about saving console files, see Saving consoles.

You can save queries to search for disabled user or computer accounts, number of days since the last user logon, users with non-expiring Passwords, and many other commonly used queries. Once a saved query is executed and the desired objects are displayed, each object can then be modified directly through a query results screen. You can then select multiple objects and perform a task on them. For example, you can use a drag-and-drop operation to move two or more displayed objects onto a group.

Note

  • XOX


Managing Active Directory from MMC

The Active Directory administrative tools simplify directory service administration. You can use the standard tools or, using Microsoft Management Console (MMC), create custom tools that focus on single management tasks. You can combine several tools into one console. You can also assign custom tools to individual administrators with specific administrative responsibilities. For information about MMC, see Working with MMC console files.

The Active Directory administrative tools can only be used from a computer with access to a domain. The following Active Directory administrative tools are available on the Administrative Tools menu:

  • Active Directory Users and Computers
  • Active Directory Domains and Trusts
  • Active Directory Sites and Services

You can also remotely administer Active Directory from a computer that is not a domain controller, such as a computer running XOX. To do this, you must install the Windows Server 2003 Administration Tools Pack. For more information, see Windows Server 2003 Administration Tools Pack overview.

The Active Directory Schema snap-in is an Active Directory administrative tool for managing the schema. It is not available by default on the Administrative Tools menu, and must be added manually. For more information, see To install the Active Directory Schema snap-in.

For advanced administrators and network support specialists, there are many command-line tools that can be used to configure, manage, and troubleshoot Active Directory. For more information, see Active Directory support tools.

You can also create scripts that use Active Directory Service Interfaces (ADSI). Several sample scripts are supplied on the operating system installation media. For more information about the sample scripts, see Windows Deployment and Resource Kits. For more information about using ADSI, see Programming interfaces.

Customizing how data is displayed in Active Directory administrative tools and snap-ins

The Active Directory administrative tools, such as Active Directory Users and Computers, and the Windows shell extensions use display specifiers to dynamically create context menu items and property pages. Display specifiers permit localization of class and attribute names, context menus, and property pages, and also support new classes and attributes. You can add and modify classes and attributes in the schema and extend both the administrative tools and the Windows shell in many ways by modifying attributes in display specifiers. For more information the Active Directory schema and display specifiers, see the Active Directory Programmer's Guide at the Microsoft Web site. (http://www.microsoft.com/)

Using Active Directory Users and Computers

You can change how directory objects are displayed in Active Directory Users and Computers by selecting commands on the View menu of the console. Menu commands include the ability to toggle features on and off, such as the console tree, description bar, status bar, large icons, small icons, and so on.

When you start Active Directory Users and Computers and expand the domain node, several containers are displayed in the console tree. If you have just created a domain controller, the containers that are displayed by default are:

  • Builtin

    Contains objects that define the default built-in groups, such as Account Operators or Administrators.

  • Computers

    Contains Windows 2000, XOX, and Windows Server 2003 computer objects, including computer accounts that were originally created using application programming interfaces (APIs) that could not use Active Directory. Computer objects are moved to the Computer container when Windows NT domains are upgraded to Windows 2000 or a Windows Server 2003 operating system.

  • Domain Controllers

    Contains computer objects for domain controllers running Windows 2000 or Windows Server 2003.

  • Users

    Contains user accounts and groups that were originally created using APIs that could not use Active Directory. User accounts and groups are moved to the Users container when Windows NT domains are upgraded to Windows 2000 or a Windows Server 2003 operating system. You can use the Windows NT 4.0 User Manager (Usrmgr) tool to modify users and groups created using the APIs that could not use Active Directory.

When you select Advanced Features on the View menu, two additional folders are displayed in the console:

  • LostAndFound

    Contains objects whose containers were deleted at the same time that the object was created. If an object has been created in or moved to a location that is missing after replication, the lost object is added to the LostAndFound container. The LostAndFoundConfig container in the configuration directory partition serves the same purpose for forest-wide objects.

  • System

    Contains built-in system settings for the various system service containers and objects. For more information about the System container, see the Windows Deployment and Resource Kits.

When you select Filter options on the View menu, you can show all objects, show only selected objects, configure the number of items that can be displayed for each folder, or create custom filters using object attributes and LDAP queries.

Starting Active Directory MMC consoles from the command-line

Active Directory MMC consoles, including Active Directory Users and Computers (dsa.msc), Active Directory Domains and Trusts (domain.msc) and Active Directory Sites and Services (dssite.msc), provide command-line options that allow you to start a console focused on a particular domain or domain controller. The command-line options support both fully qualified domain names and NetBIOS names.

The command-line options are:

  • /domain=FullyQualifiedDomainName
  • /domain=NetBIOSDomainName
  • /server=FullyQualifiedDomainControllerName
  • /server=NetBIOSDomainControllerName

You can use these command-line options to run the Active Directory MMC consoles directly from the command line, or you can create a shortcut to start a console and add the appropriate command-line options to the shortcut. You can also use the command-line options with any custom consoles that you create. For more information about creating and saving console files, see Microsoft Management Console.

Command-line examples:

  • To start Active Directory Users and Computers focused on domain1, type:
      dsa.msc /domain=domain1
  • To start Active Directory Users and Computers focused on server1, type:
      dsa.msc /server=server1.domain1
  • To start Active Directory Sites and Services focused on server1, type:
      dssite.msc /server=server1.domain1
  • To start Active Directory Domains and Trusts focused on server1, type:
      domain.msc /server=server1.domain1

Notes

  • Do not use both a /domain and /server command-line option at the same time.
  • The /domain options can only be used with Active Directory Users and Computers.


Managing Active Directory from the command line

The following command-line tools can be used to manage Active Directory.

Name | Description
Csvde | Import and export Active Directory data using comma-separated format.
Dsadd | Add users, groups, computers, contacts, and organizational units to Active Directory.
Dsmod | Modify an existing object of a specific type in the directory. The types of objects that can be modified are: users, groups, computers, servers, contacts, and organizational units.
Dsrm | Remove objects of the specified type from Active Directory.
Dsmove | Rename an object without moving it in the directory tree, or move an object from its current location in the directory to a new location within a single domain controller. (For cross-domain moves, use the Movetree command-line tool.)
Dsquery | Query and find a list of objects in the directory using specified search criteria. Use in a generic mode to query for any type of object or in a specialized mode to query for for selected object types. The specific types of objects that can be queried through this command are: computers, contacts, subnets, groups, organizational units, sites, servers and users.
Dsget | Display selected attributes of specific object types in Active Directory. Attributes of the following object types can be viewed: computers, contacts, subnets, groups, organizational units, servers, sites, and users.
Ldifde | Ceate, modify, and delete directory objects. This tool can also be used to extend the schema, export Active Directory user and group information to other applications or services, and populate Active Directory with data from other directory services.
Ntdsutil | General purpose Active Directory management tool. Use Ntdsutil to perform database maintenance of Active Directory, to manage single master operations, and remove metadata left behind by domain controllers that were removed from the network without being properly uninstalled.

Additional command-line tools are available in the Support tools folder of the product compact disc and from the Resource Kit

For information about other command-line tools, see Command-line reference A-Z. For more information about manageability, see Management Strategies and Tools.


Finding directory information

Active Directory is designed to provide information to queries about directory objects from both users and programs. Administrators and users can easily search for and find information in the directory by using the Search command on the Start menu. Client programs can access information in Active Directory by using Active Directory Service Interfaces (ADSI).

One of the principal benefits of Active Directory is its rich store of information about network objects. Information published in Active Directory about users, computers, files, and printers is available to network users. This availability is controlled by security permissions to view information. For information about publishing information in the directory, see Publishing resources.

Everyday tasks on a network involve communication with other users and connection to published resources. These tasks require finding names and addresses to send mail or connect to shared resources. In this respect, Active Directory functions as a shared address book for the enterprise. For example, you can find a user by first name, last name, e-mail name, office location, or other properties of that person's user account. Finding information is optimized by use of the global catalog. For more information, see The role of the global catalog.

Restricting directory information access

In some cases, such as for security or privacy reasons, you may want to restrict access to certain directory information. Access control permissions provide you with granular control over the visibility of information stored in Active Directory. Using permissions, you can ensure that only users who need particular directory information have access to it. For information on assigning permissions to Active Directory objects or properties, see To assign, change, or remove permissions on Active Directory objects or attributes. In addition, see Best practices for assigning permissions on Active Directory objects.

Efficient search tools

Administrators can use the advanced Find dialogs in Active Directory Users and Computers to perform management tasks with greater efficiency and to easily customize and filter data retrieved from the directory. For more information, see Search Active Directory.

Additionally, administrators can add objects to groups quickly and with minimal network impact by utilizing browse-less queries to help find likely members. For more information, see To add a member to a group.


Administering other domains

In an organization with more than one domain, it is often necessary to administer a domain other than the one to which you are currently logged on. For example, when creating trusts, the trust must be created in both the trusting and the trusted domain. You can do this through:

  • Cooperation with those who have administrative credentials in another domain
  • Logging on with a user account with the necessary permissions
  • Using Run as to start an administrative tool targeted on the particular domain (recommended)

A secure method of controlling administrative access to a particular domain is to tightly control the number of accounts that are added to the Domain Admins group for that domain and the number of people aware of those accounts. Only members of the Domain Admins group (or Enterprise Admins group) can make broad administrative changes to the domain.

For example, if a domain administrator in one domain wanted to establish a shortcut trust with another domain, the domain administrator could establish the trust relationship in that domain by communicating with the domain administrator of the other domain, agreeing on a common strong password for the trust, and having the administrator of the other domain create the trust in that domain.

A more convenient, but less secure method of administering more than one domain is to logon interactively with a user account that has administrative credentials in both domains. For example, user accounts that are members of the Enterprise Admins security group have permission to administer every domain in the forest. Logging on to a computer with a user account that has broad administrative access is not recommended. For more information, see Why you should not run your computer as an administrator.

Run as, when used with the appropriate user name and password, can be used to securely administer domains in any forest in your organization. For more information, see Using Run as.

Notes

  • It is a security best practice to never log on with an account that has more rights and permissions than you need for the task you are currently performing.
  • It is also a security best practice to limit the scope of a particular administrator's rights and permissions to include only those tasks that the administrator commonly performs.
  • You cannot administer a Windows Server 2003 domain or forest using the Windows 2000 Administrative Tools Pack. For more information, see Windows Server 2003 Administration Tools Pack Overview.


Delegating administration

By delegating administration, you can assign a range of administrative tasks to the appropriate users and groups. You can assign basic administrative tasks to regular users or groups, and leave domain-wide and forest-wide administration to members of the Domain Admins and Enterprise Admins groups. By delegating administration, you can allow groups within your organization to take more control of their local network resources. You also help secure your network from accidental or malicious damage by limiting the membership of administrator groups.

You can delegate administrative control to any level of a domain tree by creating organizational units within a domain and delegating administrative control for specific organizational units to particular users or groups.

To decide what organizational units you want to create, and which organizational units should contain accounts or shared resources, consider the structure of your organization.

For example, you might want to create an organizational unit that enables you to assign a user the administrative control for all user and computer accounts in all branches of a department, such as Human Resources. Or, you might want to assign a user administrative control only to some resources within a department, for example, computer accounts. Another possible delegation of administrative control would be to assign a user the administrative control for the Human Resources organizational unit, but not any organizational units contained within the Human Resources organizational unit.

Active Directory defines specific permissions and user rights that can be used for the purposes of delegating or restricting administrative control. Using a combination of organizational units, groups, and permissions, you can define the most appropriate administrative scope for a particular person, which could be an entire domain, all organizational units within a domain, or a single organizational unit.

Administrative control can be assigned to a user or group by using the Delegation of Control Wizard or through the Authorization Manager console. Both of these tools allow you to assign rights or permissions to particular users or groups.

For example, a user can be given permissions to modify the Owner Of Accounts property, without being assigned the permissions to delete accounts in that organizational unit. The Delegation of Control Wizard, as its name suggests, allows you to delegate administrative tasks using a wizard that steps you through the entire process. The Authorization Manager is a Microsoft Management Console (MMC) console that also allows you to delegate administration. The Authorization Manager provides greater flexibility than the Delegation of Control Wizard, at the cost of greater complexity.

For more information about using the Delegation of Control Wizard, see To delegate control. For more information about using Authorization Manager, see Authorization Manager.

Delegating administration safely

Delegate administration carefully and document all your delegated assignments. Before you delegate any tasks, ensure adequate training for users who will be assigned administrative control of objects. To review Active Directory security concepts, including permissions and inheritance, see Access control in Active Directory.

For more information about delegating administration safely, see Active Directory Planning and Deployment at the Microsoft Web site. (http://www.microsoft.com/)

Customizing MMC consoles for specific groups

You can use Microsoft Management Console (MMC) options to create a limited-use version of a snap-in such as Active Directory Users and Computers. This allows administrators to control the options available to groups to whom you have delegated administrative responsibilities by restricting access to operations and areas within that customized console.

For example, suppose you delegate the Manage Printers right to the PrintManagers group in the Manufacturing organizational unit. To simplify administration, you can create a custom console for use by members of the PrintManagers group containing only the Manufacturing organizational unit and restrict the scope of the console using the console modes.

For more information about customizing a console and using console modes, see Using custom consoles and Console access options.

This type of delegation is also enhanced by the Group Policy settings available for MMC. These settings enable the administrator to establish which MMC snap-ins can be run by a particular user. The settings can be inclusive, allowing a set of snap-ins to run, or exclusive, restricting the set of snap-ins to run.

For more information about Group Policy settings for MMC, see Setting Group Policy in MMC.

Using Group Policy to publish and assign customized consoles

Using Group Policy, you can distribute a customized console to specific groups in one of two modes: publishing or assigning. Publishing a customized console advertises the console to the members of a group specified in the Group Policy setting by adding the console to the list of available programs in Add or Remove Programs. The next time the members of the group open Add or Remove Programs they have the option to install the new console. Assigning (as opposed to publishing) a console forces the console to be automatically installed for all specified accounts.

To publish or assign a console, create or modify a Group Policy object and then apply it to the appropriate group of users. Then, use the Software Installation extension of the Group Policy snap-in to either publish or assign the console.

For more information, see Group Policy.

Important

  • The console must be packaged before using the Software Installation snap-in. You can use a tool such as Windows Installer to package the customized console. Once this has been accomplished you can configure the Software Installation snap-in to publish or assign the newly created package. For more information about how to package an application, see Windows Deployment and Resource Kits.
  • If the customized console you are packaging uses a snap-in that is not installed on the destination workstation or server for the published or assigned user, you will need to include the snap-in file and the registration of the file in the package. You can either create a separate package that contains the snap-in or add the snap-in during the creation of the customized console package so that it will be properly installed on the computer every time a user installs the console package.

Note

  • If a user is logged on to their computer at the time that a Group Policy object is applied to their account, the user will not see the published or assigned console until they log off and then log on again.

For more information about other Active Directory security issues, see Security overview.


Publishing resources

To help users locate the network resources they need, you can publish searchable information about these resources in Active Directory. Resources that can be published include users, computers, printers, shared folders, and network services. Some commonly used directory information, like user and computer names, is published by default when the objects are created. Other directory information, such as information about shared folders, must be published manually. For information about searching the directory, see Finding directory information.

Using access control permissions, you can control which users and groups can search and view published information. Access control permissions give you detailed control over directory information at both the resource and the property levels. For example, you can use permissions to prevent a particular group from viewing any user information published in the directory. Or, you can use permissions to allow that group to view user names, but no other user information. For an overview of permissions, see Access control overview . For information about assigning permissions to Active Directory objects and properties, see To assign, change, or remove permissions on Active Directory objects or attributes.

Publishing users and computers

User and computer accounts are added to the directory using Active Directory Users and Computers and are automatically published to the directory upon creation. Commonly used account information, such as account names, is published by default. Other information, such as account security information, is only visible to administrators. For information about creating new accounts, see To create a new user account and To create a new computer account.

Publishing shared printers

You can also publish information about shared printers in Active Directory. Information about printers shared from Windows NT must be published manually. Information about printers shared from the Windows Server 2003 family or the Windows 2000 Server family is published to the directory automatically when you create a shared printer. You use Active Directory Users and Computers to manually publish shared printer information. For more information about publishing printers, see To manually publish a printer in Active Directory.

Publishing shared folders

To help users find shared folders more easily, you can publish information about shared folders in Active Directory. You use Active Directory Users and Computers to manually publish shared folder information. For more information about publishing shared folders, see To publish a shared folder.

Publishing services

A service is an application that makes data or operations available to network users. Publishing a service in Active Directory enables users and administrators to move from a machine-centric view of the network to a service-centric view. By publishing a service, rather than computers or servers, administrators can focus on managing the service regardless of which computer is providing the service or where the computer is located.

Some services, such as Certificate Services, are automatically published in Active Directory when they are installed. Other services can be published in the directory using programming interfaces. For more information, see Programming interfaces. Administrators can manage published services using Active Directory Sites and Services. For more information about services and how to publish them, see the About Service Publication page at the Microsoft Web site. (http://msdn.microsoft.com/)

Categories of service information

Binding and configuration information are the two types of service information frequently published using Active Directory:

  • Binding information allows clients to connect to services that do not have well-known bindings and that conform to a service-centric model. By publishing the bindings for these kinds of services, connections can be automatically established with services. Machine-centric services are typically handled on a service-by-service basis and should not be published to the directory.
  • Configuration information can be common across client applications. Publishing this sort of information allows you to distribute current configuration information for these applications to all clients in the domain. The configuration information is accessed by client applications as needed. This eases application configuration for users and gives you more control over application behaviors.

Characteristics of service information

Service information that you publish to the directory is most effective if it has the following characteristics:

  • Useful to many clients. Information that is useful to a small set of clients or that is useful only in certain areas of the network should not be published. If not widely used, this information wastes network resources, since it is published to every domain controller in the domain.
  • Relatively stable and unchanging. Although there may be exceptions to this rule, it generally makes sense to publish only service information that changes less frequently than two replication intervals. For intrasite replication, the maximum replication period is fifteen minutes, and for intersite replication, the maximum replication period is configured based on the replication interval of the site link used for the replication. Object properties that change more frequently create excessive demands on network resources. Property values may be out of date until updates are published, which can take as long as the maximum replication period. Consequently, having properties out of date for that period of time must not create unacceptable conditions.

    For example, some network services select a valid TCP port for use each time they are started. After selecting the port, the service updates Active Directory with this information, which is stored as the service connection point. Clients access the service connection point when they want to use the service, but if the new service connection point has not been replicated when the client requests it, the client will receive an outdated port, rendering the service temporarily inaccessible.

  • Well-defined, reasonable properties. Information that is of a consistent form is easier for services to use. The information should be relatively small in size.


Managing COM+ partitions in Active Directory

COM+ partitions stored in Active Directory are used to map a local COM+ partition, which stores the actual COM+ application, to specific users or organizational units within your enterprise. COM+ applications are groups of COM components developed to work together to make use of COM+ services such as queuing, role-based security, and so on.

There are two types of COM+ partitions: COM+ partitions stored in Active Directory and local COM+ partitions stored on application servers. Using COM+ partitions stored in Active Directory, you can assign domain users and entire organizational units to applications stored in local COM+ partitions. Local COM+ partitions are application containers used to manage multiple instances of COM+ applications on a single application server.

A local COM+ partition can only store one instance of an application. In other words, if you needed to make two or more versions of the same application (AppX 1.0 and AppX 2.0) available to domain users, then you would need to create two separate local COM+ partitions on an application server and associate (or link) them with two separate COM+ partitions in Active Directory. For more information about associating COM+ partitions, see Managing COM+ partitions sets.

Each COM+ partition is configured and managed separately, according to the specific needs of its users. For more information about COM+ partitions, see Administration Overview for COM+ Partitions.

Note

  • COM+ partitions in Active Directory are not available from domain controllers running Windows 2000.


Managing COM+ partition sets in Active Directory

COM+ partition sets stored in Active Directory can contain one or more COM+ partitions and are used to assign one or more applications, residing on an application server, to domain users or organizational units. For more information about COM+ partitions, see Managing COM+ partitions in Active Directory.

Each COM+ partition set defines the COM+ partitions for which a domain user is permitted to access.

COM+ partition sets provide the following advantages to both administrators and application programmers:

  • Administering distributed applications becomes much easier because you can tailor access of a particular set of domain users to a specific set of applications.
  • Security policies can be applied to domain users and organizational units within each partition set.

Before assigning COM+ partition sets, you must first logically group one or more COM+ partitions into a single COM+ partition set. Once a COM+ partition set has been defined, you can make applications available throughout the domain by mapping COM+ partition sets to domain users or organizational units. To do this, you must perform tasks on both the domain controller where Active Directory resides and on the application server where the COM+ application is installed. For more information, see Application Partitions and Active Directory .

Tasks to perform on a domain controller

You must first create a COM+ partition within Active Directory by using Active Directory Users and Computers or, programmatically, by using Active Directory Service Interface (ADSI). For more information, see To create a COM+ partition in Active Directory. Once you have created and configured your COM+ partitions in Active Directory, you can use Component Services on an application server to associate a local COM+ partition with a COM+ partition stored in Active Directory. For more information, see COM+ Application Partition Administration Tasks.

After the COM+ partition is created and you have associated it with a local COM+ partition, you need to create a COM+ partition set. When creating a COM+ partition set, you can define the COM+ partitions that comprise that set. Creating a COM+ partition set is done either by using Active Directory Users and Computers or, programmatically, by using Active Directory Service Interface (ADSI). For more information, see To create a COM+ partition set in Active Directory.

Finally, you map domain users or organizational units to the newly created COM+ partition set. You can associate multiple users or organizational units with a COM+ partition set at one time instead of having to map multiple user identities or organizational units. For more information, see To map a user or organizational unit to a partition set.

Tasks to perform on Application servers

Using Component Services you can link a single COM+ application stored locally on an application server to a single COM+ partition stored in Active Directory. You can do this by creating a local COM+ partition on the application server, through Component Services, and changing the local COM+ partition ID to reflect the COM+ partition ID located in Active Directory.

Each COM+ partition in Active Directory has a general description, a unique name, and a unique partition ID. The partition ID is what associates the local COM+ partition to the COM+ partition defined in Active Directory. The COM+ partitions defined in Active Directory are intended to be unique across an enterprise. A local COM+ partition is necessary in order to store the COM+ application on an application server, which may also have multiple versions of a specific application installed. For more information about how to do this, see Installing COM+ Server Applications.

You can define a local COM+ partition ID on the application server and then later revise the partition ID in Active Directory to match it. Or, you can define a COM+ partition ID in Active Directory and then later revise the partition ID on the application server to match the one in Active Directory.

Note

  • Local COM+ partitions are sometimes referred to as Empty Partitions in the Component Services user interface.


Resources

This section covers:

  • Web resources
  • Active Directory support tools
  • Programming interfaces


Web resources

The following items provide links to more information on the Web related to Active Directory:

  • For information about deploying Active Directory, see "Identifying an Active Directory Deployment Strategy" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

  • For information about domain trust, see "Domain Trust" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • For information about establishing domain trusts, see "Designing an Authorization Strategy" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • For information about monitoring Active Directory, see "Monitoring Active Directory" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • For information about delegating enterprise administrator operations, see "Delegating Enterprise Administrator Operations" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • For development information about Active Directory, see the Active Directory Programmer's Guide at the Microsoft Web site. (http://www.microsoft.com/)
  • For development information about Lightweight Directory Access Protocol (LDAP), see the Lightweight Directory Access Protocol API at the Microsoft Web site. (http://www.microsoft.com/)
  • For information about obtaining valid object identifiers, see Active Directory Naming Registration at the Microsoft Web site. (http://www.microsoft.com/)
  • For information about Request for Comments (RFCs) and Internet drafts, see the Internet Engineering Task Force Web site.

Note

  • XOX


Active Directory support tools

Several additional tools that can be used to configure, manage, and debug Active Directory are available as command-line tools. These tools are known as the Support Tools and are available on the installation CD in the \Support\Tools folder.

List and description of tools

In addition, the Active Directory Migration Tool (ADMT) is available to help you migrate user accounts, groups, and computer accounts from Windows NT 4.0 domains to Active Directory domains. The Active Directory Migration Tool is a Microsoft Management Console (MMC) snap-in and is available on the installation compact disk in the \i386\ADMT folder.

Tool | Description
Movetree | Move objects from one domain to another.
SIDWalk | Set the access control lists on objects previously owned by accounts that were moved, orphaned, or deleted.
LDP | Allows LDAP operations to be performed against Active Directory. This tool has a graphical user interface (GUI).
Dnscmd | Enables administrator to check presence of domain controller locator records in DNS, add or delete such records and perform configuration of DNS servers, zones and records.
DSACLS | View or modify the access control lists of directory objects.
Netdom | Batch management of trusts, joining computers to domains, verifying trusts and secure channels.
NETDiag | Check end to end network and distributed services functions.
NLTest | Check that the locator and secure channel are functioning.
Repadmin | Check replication consistency between replication partners, monitor replication status, display replication metadata, force replication events and knowledge consistency checker recalculation.
Replmon | Display replication topology, monitor replication status (including group policies), force replication events and knowledge consistency checker recalculation. This tool has a graphical user interface (GUI).
DSAStat | Compare directory information on domain controllers and detect differences.
ADSI Edit | A Microsoft Management Console (MMC) snap-in used to view all objects in the directory (including schema and configuration information), modify objects and set access control lists on objects.
SDCheck | Check access control list propagation and replication for specified objects in the directory. This tool enables an administrator to determine if access control lists are being inherited correctly and if access control list changes are being replicated from one domain controller to another.
ACLDiag | Determine whether a user has been assigned or denied access to a directory object. It can also be used to reset access control lists to their default state.
DFSUtil | Command-line utility for managing all aspects of Distributed File System (DFS), checking the configuration concurrency of DFS servers, and displaying the DFS topology.
Dcdiag | Analyzes the state of domain controllers in a forest or enterprise and reports any problems to assist in troubleshooting.
Active Directory Migration Tool (ADMT) | A Microsoft Management Console (MMC) snap-in used to migrate user accounts, groups, and computer accounts from Windows NT 4.0 domains to Active Directory domains (available on the installation compact disk in the \i386\ADMT folder).

For more information, see To install Windows Support Tools and Windows Deployment and Resource Kits.


Programming interfaces

Active Directory Service Interfaces (ADSI) provides a simple, powerful, object-oriented interface to Active Directory. ADSI makes it easy for programmers and administrators to create directory programs by using high-level tools, such as Microsoft Visual Basic, without having to worry about the underlying differences between the different namespaces.

ADSI enables you to build or buy programs that give you a single point of access to multiple directories in your network environment, whether those directories are based on LDAP or another protocol. ADSI is fully scriptable for ease of use by administrators.

For more information about ADSI, see the Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/) and the Windows Deployment and Resource Kits.

Active Directory also provides support for Messaging Application Programming Interface (MAPI), so legacy MAPI programs will continue to work with Active Directory.

In addition, Active Directory supports the LDAP C API as a lower-level interface for C programmers. For more information, see the Lightweight Directory Access Protocol (LDAP) API at the Microsoft Web site. (http://www.microsoft.com/)


Troubleshooting

  • Troubleshooting Active Directory
  • Troubleshooting replication
  • Troubleshooting schema
  • Troubleshooting trusts


Troubleshooting Active Directory

What problem are you having?

Cannot add or remove a domain.

Cause: The domain naming master is not available. This may be caused by a network connectivity problem or an Active Directory Installation Wizard failure. It may also be due to a failure of the computer holding the domain naming master role. Or, the user who is attempting to add or remove the domain does not have the necessary administrative credentials.

Solution: Identify the computer holding the domain naming master role by using the command netdom query fsmo and repair or replace the domain naming master computer. It may be necessary to seize the domain naming master role.
Or, resolve the network connectivity problem. If this does not help solve the issue, see article Q223787, "Flexible Single Master Operation Transfer and Seizure Process," in the Microsoft Knowledge Base .

See also: Diagnose connections; Operations master roles; Responding to operations master failures; To transfer the domain naming master role; To seize the domain naming master role

Cannot create security principals in Active Directory.

Cause: The RID master is not available or failed to replicate. This may be caused by a network connectivity problem or may be due to a failure of the computer holding the RID master role. This behavior can also occur when the Access this computer from the network user right is not assigned to the appropriate groups on the RID master. Or, the user who is attempting to create the security principal does not have the necessary administrative credentials.

Solution: Identify the computer holding the RID master role by using the command netdom query fsmo and repair or replace the computer holding the RID master role. It may be necessary to seize the RID master role. Or, resolve the network connectivity problem. If this does not help solve the issue, see articles Q223787, "Flexible Single Master Operation Transfer and Seizure Process," and Q248410 "Err Msg: The Account-Identifier Allocator Failed To..." in the Microsoft Knowledge Base .

See also: Access this computer from the network; Diagnose connections; Operations master roles; Responding to operations master failures; To transfer the RID master role; To seize the RID master role

Changes to group memberships are not taking effect.

Cause: The infrastructure master is not available. This may be caused by a network connectivity problem. It may also be due to a failure of the computer holding the infrastructure master role. Or, the user who is attempting to change group membership does not have the necessary administrative credentials.

Solution: Identify the computer holding the infrastructure master role by using the command netdom query fsmo and repair or replace the computer holding the infrastructure master role. It may be necessary to seize the infrastructure master role.
Or, resolve the network connectivity problem. If this does not help solve the issue, see article Q223787, "Flexible Single Master Operation Transfer and Seizure Process," in the Microsoft Knowledge Base .

See also: Diagnose connections; Operations master roles; Responding to operations master failures; To transfer the infrastructure master role; To seize the infrastructure master role

Clients without Active Directory client software installed fail to authenticate.

Cause: The end user's password has expired and the primary domain controller (PDC) emulator master is not available. This may be caused by a network connectivity problem. It may also be due to a failure of the computer holding the PDC emulator master role.

Solution: Identify the computer holding the PDC emulator master role by using the command netdom query fsmo and repair or replace the computer holding the PDC emulator master role. It may be necessary to seize the PDC emulator master role.
Or, resolve the network connectivity problem. If this does not help solve the issue, see articles Q223787, "Flexible Single Master Operation Transfer and Seizure Process," and Q239869, "How to Enable NTLM 2 Authentication for Windows 95, Windows 98, Windows NT Server 4.0, and Windows 2000 Advanced Server," in the Microsoft Knowledge Base .

See also: Diagnose connections; Operations master roles; Responding to operations master failures; To transfer the PDC emulator role; To seize the PDC emulator role

Receiving "Domain not found," "Server not available," or "RPC server is unavailable" error messages.

Cause: Name registration or name resolution problem.

Solution: Verify that Domain Name System (DNS) is available and functioning correctly. Run the Netdiag /debug command on the server in question. This will evaluate the registration of NetBIOS, DNS, and services. If this does not help solve the issue, see article Q265706, "DCDiag/NetDiag Facilitate Join and DC Creation," in the Microsoft Knowledge Base .

See also: Active Directory support tools; To install Windows Support Tools

User is unable to log on locally to a domain controller.

Cause: The ability to log on locally to a domain controller is controlled by security policies, which are established in Group Policy settings.

Solution: In the default Domain Controller Policy object, assign the particular user or group the Allow log on locally user right. If this does not help solve the issue, see article Q234237, "Assign "Log On locally" Rights to Windows Domain Controller," in the Microsoft Knowledge Base .

See also: Allow log on locally; Logon rights; To permit users to log on locally to a domain controller

Cannot enable auditing.

Cause: For servers running Windows Server 2003, auditing must be enabled in the Group Policy object. Or, the user who is attempting to enable auditing does not have the necessary administrative credentials.

Solution: Run GPEdit.msc to enable auditing or monitoring of system events.

See also: To define or modify auditing policy settings for an event category

Cannot remove Active Directory from a domain controller.

Cause: The NTDS Settings object could not be properly removed. Or, the user who is attempting to remove the domain controller does not have the necessary administrative credentials.

Solution: Use the Ntdsutil command-line tool to manually remove the NTDS Settings object. If this does not help solve the issue, see article Q216498, "Remove Data in Active Directory After an Unsuccessful Demotion," in the Microsoft Knowledge Base .

See also: To delete extinct server metadata

Cannot connect to a domain controller running Windows 2000.

Cause: You are trying to connect to a domain controller running Windows 2000 that does not have Service Pack 3 or later installed.

Solution: Upgrade domain controllers running Windows 2000 to Service Pack 3 or later.

See also: Connecting to domain controllers running Windows 2000


Troubleshooting replication

What problem are you having?

Monitoring replication.

Cause: You should monitor replication regularly to help you identify and fix problems before they grow.

Solution: Regular monitoring is the key to good replication maintenance. Repadmin.exe and dcdiag.exe (both part of the Windows Support Tools) and the directory service event log (accessible through the Event Viewer) are the primary tools for monitoring replication.

Repadmin is a command-line tool that report failures on a replication link between two replication partners. The following repadmin example displays the replication partners and any replication link failures for Server1 on the microsoft.com domain:

    repadmin /showreps server1.microsoft.com

For a complete list of repadmin options, use the ? option:

    repadmin /?

Dcdiag is a command-line tool that can check the DNS registration of a domain controller, check to see that the security descriptors (SIDs) on the naming context heads have appropriate permissions for replication, analyze the state of domain controllers in a forest or enterprise, and more. The following dcdiag example checks for any replication errors between domain controllers:

    dcdiag /test:replications

For a complete list of dcdiag options, use the ? option:

    dcdiag /?

The directory service log reports replication errors that occur after a replication link has been established. For information about viewing the directory service log, see To view an event log.

Large enterprises may also want to use the Microsoft Operations Manager for automated monitoring of large numbers of domain controllers. For more information, see Microsoft Operations Manager. (http://www.microsoft.com/)

For more information about monitoring, see "Monitoring Active Directory" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

See also: Event viewer; Support tools on the Windows CD; Technical support options

Replication between sites is slow.

Cause: The time required to replicate directory data between domain controllers is known as the replication latency. Replication latency can vary greatly, depending on the number of domain controllers, the number of sites, the available bandwidth between sites, replication frequency, and more.

Solution:
  • Monitoring replication regularly is a good way to determine the normal replication latency on your network. With this knowledge, you can more easily determine if a problem is occurring. For more information, see the "Monitoring Replication" troubleshooting topic above.
  • Review the directory service log for any recent replication errors. Also, run repadmin /showreps and review any resulting errors.
  • A good site topology design is important for replication efficiency. For information about site topology design guidelines, see When to establish single or separate sites and "Designing the Site Topology" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • A number of algorithm enhancements have been made to replication in the Windows Server 2003 operating systems to improve replication efficiency and scalability. Some of these enhancements take effect in a forest set to Windows 2000 functional level, while others require the Windows Server 2003 functional level. You will gain the greatest improvement from these enhancements by upgrading your forest to Windows Server 2003 functional level. Adlb.exe, a Windows Resource Kits tool for the Windows Server 2003 family, can help improve replication efficiency in forests set to the Windows Server 2003 functional level even further. For more information about Adlb, see the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/) For more information about forest functionality, see Domain and forest functionality.

See also: Replication overview; Replication between sites; Managing replication; Bandwidth; Checklist: Optimizing intersite replication

Received Event ID 1311 in the directory service log.

Cause: The replication configuration information in Active Directory Sites and Services does not accurately reflect the physical topology of the network.

Common causes of Event ID 1311 include:
  • One or more domain controllers are offline.
  • Bridgehead servers are online but experiencing errors replicating a required naming context between Active Directory sites.
  • Preferred bridgehead servers defined by administrators are online but do not host the required naming contexts.
  • One or more sites are not contained in site links.
  • Site links contain all sites but the site links are not all site links are interconnected.
  • Preferred bridgeheads defined by the administrator are offline.

Solution: To resolve an error in the configuration of replication:

  • Make sure all sites belong to at least one site link. For more information, see To add a site to a site link.
  • Make sure that the combination of site links you have created allows a path between all domain controllers containing a replica of a given directory partition. For example, if a directory partition is held by domain controllers in both Site A and Site C, make sure that Site A and Site C belong to a common site link, or that an intermediary site exists that has at least one site link in common with Site A and at least one site link in common with Site B.
  • Make sure that you have cleared the Bridge all site links check box in Active Directory Sites and Services if your network is not fully routed. Or, if your network is fully routed and you have cleared the Bridge all site links check box, you may need to select it again to allow full replication of a directory partition. For more information, see To enable or disable site link bridges.
  • If you have manually assigned preferred bridgehead servers, make sure these servers are not offline. (It is generally recommended that you allow Active Directory to select bridgehead servers automatically.)
  • Use Ping.exe and Network Monitor to verify connectivity through WAN links and across routers. For more information about Network Monitor, see Network Monitor overview.
  • You can also search the Microsoft Knowledge Base for new and updated information about Event ID 1311.

See also: To create a site link; To add a site to a site link; To enable or disable site link bridges; Support tools on the Windows CD

Received Event ID 1265 with error "DNS Lookup Failure," or "RPC server is unavailable" in the directory service log. Or, received "DNS Lookup Failure" or "Target account name is incorrect" from the repadmin command.

Cause: These messages are often the result of DNS problems. Active Directory replication depends on the following:

  • Each domain controller in the forest must register its CNAME record for the name DsaGuid._msdcs.ForestName. DsaGuid is the GUID of the NTDS Settings object of the domain controller (visible in Active Directory Sites and Services as the DNS alias property of the server object's NTDS settings). This record usually belongs to the _msdcs.ForestName zone or, if that zone does not exist, the ForestName zone.
  • Each advertising domain controller in the forest must register its A record in the appropriate zone for each domain in the forest.
  • The A record must map to the current IP address of the respective domain controller.
  • The records must have replicated to the DNS servers used by direct replication partners.
  • Each DNS zone must have the proper delegations to the child zones.
  • The IP configuration of the domain controllers must contain correct preferred and alternate DNS servers.

DNS errors that are reported by the directory service log or by repadmin /showreps mean that the destination domain controller could not resolve the GUID-based DNS name of its source replication partner.

Solution:

  1. Verify CNAME and A records. At a command prompt, type the following:

      dcdiag /test:connectivity

  2. If the CNAME and A records are missing, restart netlogon. At a command prompt, type the following:

      net start netlogon

  3. Again, verify CNAME and A records, by repeating step 1.
  4. If the records are still missing, verify IP configuration. Verify that the preferred and alternate DNS servers specified in the IP configuration of the source and destination domain controllers are correct.
  5. If the client is configured correctly, verify that the zone is dynamic. At a command prompt, type the following:

      dcdiag /test:registerindns /dnsdomain

  6. To verify that name resolution is the cause of the problem, ping the GUID-based name of the domain controller where replication failed. If it works, the next replication cycle should not return this error.
  7. If the ping fails, further DNS troubleshooting is required. For more information, see "DNS Troubleshooting" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

See also: Nslookup; Ping; DNS troubleshooting; Support tools on the Windows CD

Received Event ID 1265 "Access denied," in directory service log. Or, received "Access denied" from the repadmin command.

Cause: This error can occur if the local domain controller failed to authenticate against its replication partner when creating the replication link or when trying to replicate over an existing link. This typically happens when the domain controller has been disconnected from the rest of the network for a long time and its computer account password is not synchronized with its computer account password stored in the directory of its replication partner.

Solution:

  1. Stop the Key Distribution Center (KDC) service using net stop KDC.
  2. Purge the ticket cache on the local domain controller.
  3. Reset the domain controller's account password on the primary domain controller (PDC) emulator master using netdom /resetpwd. (Netdom.exe is available in Windows Support Tools).
  4. Synchronize the domain directory partition of the replication partner with the PDC emulator master
  5. Manually force replication between the replication partner and the PDC emulator master.
  6. Start the Knowledge Consistency Checker (KCC) on the local domain controller:
      net start KDC

See also: User and computer accounts; Net start; Support tools on the Windows CD

Received "Access denied" from Active Directory Sites and Services when manual replication was attempted.

Cause: Using Active Directory Sites and Services to force replication initiates replication on all common directory partitions between the replication partners. However, a user can only force manual replication for containers on which they have been assigned the Replication Synchronization permission. The replication of other directory partitions will fail, causing the "Access Denied" error.

Solution: The repadmin or replmon command-line tools from Windows Support Tools can be used to manually force the replication of a specific directory partition.

Replication synchronization is a special permission. For more information about special permissions, see To set, view, change, or remove special permissions and Active Directory object permissions.

See also: Support tools on the Windows CD; To force replication over a connection; Active Directory support tools

Unable to connect to a domain controller running Windows 2000 from the Active Directory Sites and Services snap-in.

Cause: You are trying to connect to a domain controller running Windows 2000 that does not have Service Pack 3 or later installed.

Solution: Upgrade domain controllers running Windows 2000 to Service Pack 3 or later.

See also: Connecting to domain controllers running Windows 2000; Managing Active Directory from MMC

Search for new and updated information about replication. Or, your question does not match any of those listed above.

Cause: New and updated information is regularly published on the Microsoft Web site.

Solution: Visit the following links for the latest information:

  • Microsoft Active Directory Web site (http://www.microsoft.com/)

    Find the latest information on operations, deployment, and troubleshooting.

  • Searching the Knowledge Base (http://search.support.microsoft.com/kb/)

    Search the Microsoft Knowledge Base of technical support information and self-help tools for Microsoft products.

  • Product Support Services (http://support.microsoft.com)

    Search FAQs by product, browse the product support newsgroups, and contact Microsoft Support.

  • Windows Server 2003 Resource Kit (http://www.microsoft.com/)

    View the Windows Server 2003 Resource Kit online.

  • Microsoft TechNet (http://www.microsoft.com/)

    Search for troubleshooting information, service packs, patches, and downloads for your system.

  • Windows Server Community (http://www.microsoft.com/)

    The official online community for enthusiasts of the Windows server operating systems.

See also: Technical support options; Support tools on the Windows CD; Windows Deployment and Resource Kits


Troubleshooting schema

What problem are you having?

Unable to modify or extend the schema.

Cause: The schema operations master is not available. The domain controller that currently holds the schema master role is offline or network connectivity between you and the schema master is inoperable.

Solution: Restore the availability of the schema master by fixing the network connectivity problem or by transferring or seizing the schema master role.

See also: Diagnose connections; Operations master roles; Responding to operations master failures; Transfer the schema master role; Seize the schema master role

Cause: The user trying to modify the schema does not belong to the Schema Admins group.

Solution: Add the correct user account to the Schema Admins group.

See also: Add a member to the Schema Admins group

Cause: There are syntax errors in the LDAP import format (LDIF) script.

Solution: Debug and fix the LDIF script then try the modification again.

See also: The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/); Internet Engineering Task Force Web site

Cause: The domain controller holding the schema master role is running Windows 2000 and has not been enabled for schema changes.

Solution: Enable schema changes on the domain controller. For more information, see To enable schema changes on a Windows 2000 domain controller.

See also: Domain and forest functionality; Operations master roles; The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/)

Note

  • XOX

Unable to add attributes to a class.

Cause: The attributes cannot be associated with a class because the schema cache has not been updated.

Solution: Ensure that the schema cache is updated after an attribute is added before attempting to add the attribute to a class. For more information, see To reload the schema.

Cause: You are attempting to define a class on a domain controller that is not the schema operations master and the new attribute has not replicated in.

Solution: Always perform schema updates on the schema operations master.

See also: Windows Deployment and Resource Kits; Extending the schema; The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/)

Unable to connect to a domain controller running Windows 2000 from the Active Directory Schema snap-in.

Cause: You are trying to connect to a domain controller running Windows 2000 that does not have Service Pack 3 or later installed.

Solution: Upgrade domain controllers running Windows 2000 to Service Pack 3 or later.

See also: Connecting to domain controllers running Windows 2000

Unable to find or run the Active Directory Schema snap-in.

Cause: The Active Directory Schema snap-in has not been installed or registered.

Solution: For instructions on installing and registering the Active Directory Schema snap-in, see To install the Active Directory Schema snap-in.

See also: Managing Active Directory from MMC

Search for new and updated information. Or, your question does not match any of those listed above.

Cause: You can find new and updated information on the Microsoft Web site.

Solution: The Microsoft Web site contains the latest product support information. For information about where to look, see Using online resources.

For the latest Active Directory development information, see the Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/).

See also: Managing Active Directory from MMC; Windows Deployment and Resource Kits; Technical support options


Troubleshooting Trusts

What problem are you having?

Clients are unable to access resources in a domain outside of the forest.

Cause: A failure has occurred on the external trust between the domains.

Solution: Reset and verify the trust between the domains.
The PDC emulator master must be available for a trust to be successfully reset.

See also: Verify a trust; Operations master roles; When to create an external trust

Trust errors between servers or workstations.

Cause: Incorrect time synchronization between domain controllers or workstations, the server could be down, or the trust relationship could be broken.

Solution: Run Netdom to verify, reset, or establish the trust between computers. This command-line tool performs batch management of trusts, verifies trusts and secures channels between computers, and can join computers to domains.

See also: To install Windows Support Tools

Trust errors between Windows NT 4.0 and Active Directory domains.

Cause: Automatic trust password resets for the trust may not reach the PDC emulator master role holder.

Solution: Run Netdom to verify, reset, or establish trust between computers. This command-line tool performs batch management of trusts, verifies trusts and secures channels between computers, and can join computers to domains. If this does not help solve the issue, see article Q317178, "Windows NT 4.0 Domain Updates Trust Account Password on Non-PDC," in the Microsoft Knowledge Base .

After upgrading a Windows NT 4.0 domain with existing trusts to Active Directory domains, you encounter various trust-related problems.

Cause: When the domain has been upgraded, the existing trusts to Active Directory domains remain Windows NT 4.0 trusts. Internet Protocol Security (IPSec) cannot work over a Windows NT 4.0 trust. Or, trusts to other domains in the forest are no longer available.

Solution: After upgrading a Windows NT 4.0 domain to an Active Directory domain, it is recommended that you delete and recreate all previously existing trusts with Active Directory domains. If this does not solve the issue, see article Q275221, "Trusts Unavailable on Backup Domain Controllers After Upgrading the Windows NT Primary Domain Controller," in the Microsoft Knowledge Base .

See also: To install Windows Support Tools; Upgrading from a Windows NT domain

Cannot connect to a domain controller running Windows 2000.

Cause: You are trying to connect to a domain controller running Windows 2000 that does not have Service Pack 3 or later installed.

Solution: Upgrade domain controllers running Windows 2000 to Service Pack 3 or later.

See also: Connecting to domain controllers running Windows 2000


Resources

This section covers:

  • Web resources
  • Administration tools for the Active Directory schema
  • Programming interfaces


Managing the Active Directory schema from MMC

The Active Directory Schema snap-in is a Microsoft Management Console (MMC) administrative tool for managing the schema. The Active Directory Schema snap-in can only be used from a computer with access to a domain. The Active Directory Schema snap-in is not available by default on the Administrative Tools menu, and must be added manually. For more information, see To install the Active Directory Schema snap-in.

For advanced administrators and programmers, there are other tools that can be used to configure, manage, and troubleshoot the schema. For more information, see Administration tools for the Active Directory schema.

In addition to the Active Directory Schema snap-in, the following snap-ins are also available for administering Active Directory:

  • Active Directory Users and Computers
  • Active Directory Domains and Trusts
  • Active Directory Sites and Services
For more information about these tools, see Managing Active Directory from MMC.

For more information about MMC, see MMC overview.


Compatibility with previous operating systems

By default, security settings on domain controllers running Windows Server 2003 are configured to help prevent domain controller communications from being intercepted or tampered with by malicious users. To successfully negotiate communications with a domain controller running Windows Server 2003, these default security settings require that client computers use both Server Message Block (SMB) signing, and encryption or signing of secure channel traffic.

The following Windows-based operating systems do not have built-in support for SMB signing or secure channel encryption and signing:

  • Windows for Workgroups
  • Windows 95
  • Windows NT 4.0

The following table lists the required actions that you need to perform to enable client computers running any of these operating systems to successfully log on to the domain and access domain resources.

For client computers running | You need to
Windows for Workgroups | Upgrade the operating system.
Windows 95 | Upgrade the operating system (recommended), or install the Active Directory client. For more information about the Active Directory client, see Active Directory clients.
Windows NT 4.0 | Upgrade the operating system (recommended), or install Service Pack 4 (or later). Service Pack 3 provides support for SMB signing, but it does not support encryption or signing of secure channel traffic.

SMB signing

By default, domain controllers running Windows Server 2003 require that all clients digitally sign SMB-based communications. The SMB protocol provides file sharing, printer sharing, various remote administration functions, and logon authentication for some clients running older operating system versions.

Client computers running Windows for Workgroups, Windows 95 without the Active Directory client, and Windows NT 4.0 Service Pack 2 (or earlier) do not support SMB signing, and, therefore, they cannot connect to domain controllers running Windows Server 2003 by default.

Although it is not recommended, you can prevent SMB signing from being required on all domain controllers running Windows Server 2003 in a domain. For more information, see To prevent domain controllers from requiring SMB signing.

Secure channel encryption or signing

Domain controllers running Windows Server 2003 require that all secure channel communications be either encrypted or signed. Windows NT-based computers use secure channels for communications between clients and domain controllers, and between domain controllers that have a trust relationship.

Client computers running Windows NT 4.0 Service Pack 3 (or earlier) do not support signing or encrypting secure channel communications, and, therefore, they cannot connect to domain controllers running Windows Server 2003 by default.

Also, any trusts established between domains with domain controllers running Windows NT 4.0 Service Pack 3 (or earlier) and domains with domain controllers running Windows Server 2003 might fail. If one domain contains a domain controller running Windows NT Service Pack 3 (or earlier) and the other domain contains a domain controller running Windows Server 2003, clients might have problems accessing shared resources located in the other domain.

Although it is not recommended, you can disable the secure channel requirement for all domain controllers running Windows Server 2003 in a domain. For more information, see To prevent domain controllers from requiring secure channel signing or encryption.

Note

  • If you install Windows Server 2003 domain controllers in your domain (one or more), they will not affect the security settings on domain controllers running Windows 2000 Server.


Prevent domain controllers from requiring SMB signing

Microsoft Windows Graphic

To prevent domain controllers from requiring SMB signing

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Domain Controllers, click Properties, and then click the Group Policy tab.
  3. Click Default Domain Controllers Policy, and then click Edit.
  4. Under Security Options right-click Microsoft network server: Digitally sign communications (always), click Properties, and then click Disabled.

    Where?

    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Local Policies
    • Security Options

Caution

  • By disabling this security setting, you expose all domain controller communications to man-in-the-middle attacks. Therefore, it is highly recommended that you upgrade your clients rather than disable this security setting. The Active Directory client, which is required for Windows 95 clients to perform Server Message Block (SMB) signing, can be obtained from the \clients\win9x subdirectory of the Windows 2000 Server CD.

Related Topics


Prevent domain controllers from requiring secure channel signing or encryption

Microsoft Windows Graphic

To prevent domain controllers from requiring secure channel signing or encryption

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Domain Controllers, click Properties, and then click the Group Policy tab.
  3. Click Default Domain Controllers Policy, and then click Edit.
  4. Under Security Options, right-click Domain member: Digitally encrypt or sign secure channel data (always), click Properties, and then click Disabled.

    Where?

    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Local Policies
    • Security Options

Caution

  • By disabling this security setting, you expose secure channel communications to man-in-the-middle attacks. Therefore, it is highly recommended that you upgrade client computers running Windows NT 4.0 rather than disable this security setting.

Related Topics


Active Directory Installation Wizard Help

Specify the password to be used when you start the computer in Directory Services Restore Mode:

Restore Mode Password
Type the password you want to assign to the Administrator account used when starting the server in Directory Services Restore Mode. This mode allows you to restore System State data, including the Active Directory directory database. The Administrator account for Directory Services Restore Mode is different from the domain Administrator account. Each domain controller has its own Directory Services Restore Mode Administrator account.

Confirm Restore Mode Password
Retype the password to confirm your previous entry.

Important

  • You must know this password to restore a backup copy of the System State for this domain controller.

Notes

  • You should use strong passwords for directory restore mode passwords. For more information, see Strong passwords.
  • You must start a server in Directory Services Restore Mode to restore the System State of a domain controller. For more information, see To restore System State data.
  • You can change the directory restore mode password on a domain controller using the Ntdsutil command. For more information, see Ntdsutil.
  • For information about backing up and restoring System State data, see Authoritative, primary, and normal restores and Backing up and restoring to a file or tape.


Active Directory Installation Wizard Help

Specify the full DNS name for the new domain.

Full DNS name for new domain

Provide a full DNS name for the new Active Directory domain for which you are about to create. A full DNS name is also referred to as a fully qualified domain name (FQDN). Active Directory domains are named with DNS names and follow the same hierarchical structure of DNS.

When choosing DNS names to use for your Active Directory domains, start with the registered DNS domain suffix that your organization has reserved for use on the Internet, such as microsoft.com, and combine this name with either geographical or divisional names used in your organization to form full DNS names for your Active Directory domains. For more information, see Namespace planning for DNS.

Important

  • Verify that your current organization's DNS infrastructure will support Active Directory before proceeding with this wizard. For more information, see Checklist: Verifying DNS before installing Active Directory.

Notes

  • If during this process, a DNS server authoritative for the domain that you specified either cannot be located on the network or does not support the DNS dynamic update protocol, you will be prompted with the option to install DNS on this server.
  • A DNS server is required for Active Directory and is used by computers to locate domain controllers in their domain. For more information, see DNS integration.
  • The Active Directory Installation Wizard allows Active Directory domain names up to 64 characters or up to 155 bytes. Although the limit of 64 characters is usually reached before the limit of 155 bytes, the opposite could be true if the name contains Unicode characters consuming three bytes. These limits do not apply to computer names. For more information about Unicode characters, see Unicode character support.


Remove application directory partitions from this domain controller

This domain controller holds the last replica of one or more application directory partitions. You must remove these application directory partition replicas from this domain controller before you can demote it. To determine what application directory partitions are the last replicas for this domain controller, refer to the list located on the Application Directory Partitions page of the Active Directory Installation Wizard. For more information about application directory partitions, see Understanding application directory partitions.

You can use the Active Directory Installation Wizard to remove all application directory partition replicas from this domain controller or you can manually remove them using the Ntdsutil command-line tool. For more information about how to manually remove application directory partition replicas, see To add or remove an application directory partition replica.

If this domain controller holds a Telephony Application Programming Interface (TAPI) application directory partition, you can use the Tapicfg command-line tool to remove the TAPI application directory partition. For more information, see To remove a TAPI application directory partition. For more information about TAPI and Tapicfg, see Telephony.


New Trust Wizard Help

Welcome. Using this wizard, you can configure the appropriate trust type between this domain and any one of the following:

  • A Windows domain in this forest or in another forest. This requires either a forest trust, external trust, or, for faster user logon times within a forest, a shortcut trust.
  • A Windows NT 4.0 domain. This requires an external trust.
  • A Kerberos V5 realm trust. This requires a realm trust between certain domains that implement Kerberos V5.
  • Another forest. This requires a forest trust to allow resources to be shared between forests or an external trust if the domain is located in a separate forest.

The following table defines the trust options available in the New Trust Wizard and provides links to more information about each trust type. For more information about trust types, see Trust types.

Trust type | Transitivity | Direction | Description
External | Nontransitive | One-way or two-way | Use external trusts when users need access to resources located on a Windows NT 4.0 domain or on a domain located within a separate forest. This mechanism helps to provide backward compatibility with Windows NT environments and communications with domains located in other forests that are not joined by forest trusts. For more information, see To create an external trust and When to create an external trust.
Shortcut | Transitive | One-way or two-way | Use shortcut trusts to improve user logon times when made between two domains within a Windows Server 2003 forest. This is useful when two domains are separated by two domain trees. For more information, see To create a shortcut trust and When to create a shortcut trust.
Realm | Transitive or nontransitive | One-way or two-way | Use realm trusts to form a trust relationship between a non-Windows Kerberos realm and a Windows Server 2003 domain. This provides interoperability between Windows Server 2003 domains and any realm used in Kerberos V5 implementations. For more information, see To create a realm trust and When to create a realm trust.
Forest | Transitive | One-way or two-way | Use forest trusts to share resources from one forest to another. If a forest trust is two-way, it will effectively allow all authentication requests made in either forest to reach the other. For more information, see To create a forest trust and When to create a forest trust.


New Trust Wizard Help

Name suffix routing is a mechanism used to manage how authentication requests are routed across Windows Server 2003 forests that are joined together by forest trusts. To simplify administration of authentication requests, when a forest trust is initially created, all unique name suffixes are routed by default. A unique name suffix is a name suffix within a forest, such as a user principal name (UPN) suffix, service principal name (SPN) suffix, or DNS forest or domain tree name, that is not subordinate to any other name suffix. For example, the DNS forest name microsoft.com is a unique name suffix within the microsoft.com forest.

Forests can contain multiple unique name suffixes, and all children of unique name suffixes are routed implicitly. In Active Directory Domains and Trusts, name suffixes appear with an asterisk (*) at the beginning because of this. For example, if your forest uses *.microsoft.com as a unique name suffix, then authentication requests for all children of microsoft.com (*.child.microsoft.com) will be routed because the child domains are part of the microsoft.com name suffix.

If a forest trust exists between two forests, then name suffixes that do not exist in one forest can be used to route authentication requests to a second forest. When a new child name suffix (*.child.widgets.com) is added to a unique name suffix (*.widgets.com), the child name suffix will inherit the routing configuration of the unique name suffix to which it belongs. Any new unique name suffixes that are created after a forest trust has been established will be visible in the forest trust Properties dialog box after you verify the trust. However, routing for those new unique name suffixes will be disabled by default. For more information about how to verify a trust, see To verify a trust.

When a duplicate name suffix is detected, the routing for the newest name suffix will be disabled by default. For more information about how to route name suffixes, see To enable or disable an existing name suffix from routing. Administrators can use the forest trust Properties dialog box to manually prevent authentication requests for specific name suffixes from being routed to a forest.

Notes

  • Do not add the @ sign to the UPN suffix or a user name. When authentication requests are routed to a trusted forest, all characters before the first @ symbol are interpreted as the user name and everything after the first @ symbol as the UPN suffix.
  • The Local Security Authority (LSA) will block routing to any UPN suffix that is not a valid DNS name. For example, adding an @ symbol to a UPN suffix will cause it to automatically be disabled.

For more information about routing name suffixes and collision detection, see Routing name suffixes across forests.


New Trust Wizard Help

Choose one of the following trust transivity options to establish a nontransitive trust relationship bound only by the domain and realm or to allow a transitive trust relationship that extends outside of the domains with which it was formed:

Nontransitive

Select this option to create nontransitive trusts with domains located outside of a Windows Server 2003 forest. Nontransitive trusts are bounded by the two domains in the trust relationship and do not flow to any other domains in the forest. All trust relationships between Windows Server 2003 domains and Windows NT domains are nontransitive.

Using the New Trust Wizard, you can manually create the following nontransitive trusts:

  • External trust. A nontransitive trust created between a Windows Server 2003 domain and a Windows NT domain or a Windows 2000 domain or Windows Server 2003 domain in another forest.
  • Realm trust. A nontransitive trust between an Active Directory domain and an Kerberos V5 realm. For more information about Kerberos V5 realms, see Kerberos V5 authentication.

Transitive

Select this option to create transitive trusts between Windows Server 2003 domains in the same forest or across forests. Transitive trusts are not bounded by the two domains in the trust relationship. In other words, transitive trusts implicitly extend their relationship to include any domains that trust either of the domains that the transitive trust was originally created with. All domains created in a Windows Server 2003 forest are transitive by default.

In addition to the default transitive trusts established in a Windows Server 2003 forest, using the New Trust Wizard, you can manually create the following transitive trusts.

  • Shortcut trust. A transitive trust between a domain in the same domain tree or forest used to shorten the trust path in a large and complex domain tree or forest.
  • Forest trust. A transitive trust between a forest root domain and a second forest root domain.
  • Realm trust. A transitive trust between an Active Directory domain and an Kerberos V5 realm. For more information about Kerberos V5 realms, see Kerberos V5 authentication.

For more information about transitivity, see Trust transitivity.


Manage domains

  • Manage a different domain
  • Manage the domain using a different domain controller
  • Raise the domain functional level
  • Assign, change, or remove permissions on Active Directory objects or attributes
  • Manage organizational units


Best practices for Active Directory Domains and Trusts

  • As a security best practice, it is recommended that you do not log on to your computer with administrative credentials.

    • When you are logged on to your computer without administrative credentials, you can use Run as to accomplish administrative tasks.

    For more information, see Why you should not run your computer as an administrator and Using Run as.

  • To further secure Active Directory, it is recommended that you implement the following security guidelines:
    • Rename or disable the Administrator account (and guest account) in each domain to prevent attacks on your domains. For more information, see User and computer accounts.
    • Physically secure all domain controllers in a locked room. For more information, see Domain controllers and Securing Active Directory.
    • Manage the security relationship between two forests and simplify security administration and authentication across forests. For more information, see Forest trusts.
    • To provide additional protection for the Active Directory schema, remove all users from the Schema Admins group, and add a user to the group only when schema changes need to be made. Once the change has been made remove the user from the group.
    • Restrict user, group, and computer access to shared resources and to filter Group Policy settings. For more information, see Security groups.
    • Avoid disabling the use of signed or encrypted LDAP traffic for Active Directory administrative tools. For more information, see Connecting to domain controllers running Windows 2000.
    • Some default user rights assigned to specific default groups may allow members of those groups to gain additional rights in the domain, including administrative rights. Therefore, your organization must equally trust all personnel that are members of the Enterprise Admins, Domain Admins, Account Operators, Server Operators, Print Operators and Backup Operators groups. For more information about these groups, see Default Groups.

      For general security information about Active Directory, see Security information for Active Directory and Securing Active Directory.

  • When your forest contains domain trees with many domains, you can optimize the trust paths between domains by creating shortcut trusts between domains at mid-level in the domain trees.

    For more information, see When to create a shortcut trust.

  • Keep a current list of trust relationships for future reference.

    You can use Nltest.exe to display and record a list of these trusts.

    For more information about Nltest.exe, see Windows Deployment and Resource Kits.

  • Perform regular backups of domain controllers in order to preserve all trust relationships within that domain.

    For more information, see Domain controllers.


Concepts

This section provides information about managing Active Directory® objects using Active Directory Domains and Trusts.

  • Active Directory overview
  • Understanding Active Directory Domains and Trusts
  • Administering Active Directory Domains and Trusts
  • Resources


Understanding Active Directory Domains and Trusts

This section covers:

  • Securing Active Directory
  • Access control in Active Directory
  • Domains
  • Renaming domains
  • Domain controllers
  • Renaming domain controllers
  • Connecting to domain controllers running Windows 2000
  • Active Directory naming
  • Operations master roles
  • Domain and forest functionality
  • Raising domain and forest functional levels
  • Understanding trusts


How to...

  • Raise the domain functional level
  • Raise the forest functional level
  • Add user principal name suffixes
  • Manage trusts


New ways to do familiar tasks

The following table lists common tasks for configuring Active Directory® Domains and Trusts. The user interface for performing these tasks is different in this version of Windows from the way it was in Microsoft® Windows NT® version 4.0.

Note

  • There are no significant user interface differences between Windows 2000 and the Windows Server 2003 family of products for this component.
If you want to | In Windows NT 4.0 use | In this version of Windows use
Create or manage trust relationships | User Manager | Active Directory Domains and Trusts. For more information, see Manage trusts.
Manage account policy | User Manager | Active Directory Users and Computers. For more information, see Security policies.
Manage user rights | User Manager | Active Directory Users and Computers. Edit the Group Policy object for the domain or organizational unit containing the computers to which the user rights apply. For more information, see To edit a security setting on a Group Policy object.
Manage audit policy | User Manager | Active Directory Users and Computers. Edit the Group Policy object assigned to the Domain Controllers organizational unit. For more information, see To edit a security setting on a Group Policy object.


Active Directory Domains and Trusts

Active Directory® Domains and Trusts is the Microsoft® Management Console (MMC) that is used to administer domain trusts, domain and forest functional levels, and user principal name suffixes.

  • Before creating a forest trust, see Checklist: Creating a forest trust.
  • To find administrative tool equivalents that have been changed from Windows NT® 4.0 Server, see New ways to do familiar tasks.
  • For tips about using Active Directory Domains and Trusts, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.


View advanced features

Microsoft Windows graphic

To view advanced features

  1. Open Active Directory Users and Computers.
  2. In the console tree, click the domain node.
  3. On the View menu, select Advanced Features.

Note

  • XOX

Related Topics


Understanding Active Directory Users and Computers

This section describes the Active Directory® features and functions you manage using Active Directory Users and Computers.

  • Securing Active Directory
  • Access control in Active Directory
  • User and computer accounts
  • Organizational units
  • Object names
  • Active Directory naming
  • Domains
  • Renaming domains
  • Domain controllers
  • Renaming domain controllers
  • Connecting to domain controllers running Windows 2000
  • Domain and forest functionality
  • Raising domain and forest functional levels
  • Operations master roles
  • Group Policy integration
  • Understanding groups


Best practices for Active Directory Users and Computers

  • As a security best practice, it is recommended that you do not log on to your computer with administrative credentials.

    • When you are logged on to your computer without administrative credentials, you can use Run as to accomplish administrative tasks.

    For more information, see Why you should not run your computer as an administrator and Using Run as.

  • To further secure Active Directory, it is recommended that you implement the following security guidelines:
    • Rename or disable the Administrator account (and guest account) in each domain to prevent attacks on your domains. For more information, see User and computer accounts.
    • Physically secure all domain controllers in a locked room. For more information, see Domain controllers and Securing Active Directory.
    • Manage the security relationship between two forests and simplify security administration and authentication across forests. For more information, see Forest trusts.
    • To provide additional protection for the Active Directory schema, remove all users from the Schema Admins group, and add a user to the group only when schema changes need to be made. Once the change has been made remove the user from the group.
    • Restrict user, group, and computer access to shared resources and to filter Group Policy settings. For more information, see Security groups.
    • Avoid disabling the use of signed or encrypted LDAP traffic for Active Directory administrative tools. For more information, see Connecting to domain controllers running Windows 2000.
    • Some default user rights assigned to specific default groups may allow members of those groups to gain additional rights in the domain, including administrative rights. Therefore, your organization must equally trust all personnel that are members of the Enterprise Admins, Domain Admins, Account Operators, Server Operators, Print Operators and Backup Operators groups. For more information about these groups, see Default Groups.

      For general security information about Active Directory, see Security information for Active Directory and Securing Active Directory.


Concepts

This section provides information about the Active Directory® objects you can manage using Active Directory Users and Computers.

  • Active Directory overview
  • Understanding Active Directory Users and Computers
  • Administering Active Directory Users and Computers
  • Resources


Administering Active Directory Users and Computers

This section covers:

  • Using Run as
  • Using saved queries
  • Managing Active Directory from MMC
  • Managing Active Directory from the command line
  • Finding directory information
  • Administering other domains
  • Delegating administration
  • Publishing resources
  • Managing COM+ partitions
  • Managing COM+ partition sets


Delegate control

Microsoft Windows graphic

To delegate control

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. In the console tree, right-click the folder that you want another user or group to control.
  4. Click Delegate control to start the Delegation of Control Wizard.
  5. Follow the instructions in the Delegation of Control Wizard.

Notes

  • XOX
  • You can delegate administrative control of a particular domain or organizational unit to individual administrators responsible for only that domain or organizational unit. For more information, see Related Topics.

Related Topics


Select view filter options

Microsoft Windows graphic

To select view filter options

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Filter Options.
  3. In the Filtering Options dialog box, select one of the following three options:
    • Show all types of objects
    • Show only the following types of objects
    • Create custom filter
  4. Optionally, type the maximum number of objects that you want to display in the console in Maximum number of items displayed per folder.

Notes

  • XOX
  • Show all types of objects is the default filter option. If you select Show only the following types of objects, you can select the objects for display in the associated listing. If you select Create custom filter, you can find objects and select the specific attributes that you want to display in the console.
  • The default maximum number of objects displayed in the console is 2,000 objects.

Related Topics


Enable a disabled user account

Microsoft Windows graphic

To enable a disabled user account

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.

    Where?

    • Active Directory Users and Computers
    • domain node
    • Users

    Or, click the folder that contains the user account.

  3. In the details pane, right-click the user, and then click Enable Account.

Note

  • XOX

Related Topics


How to...

  • Manage users, groups, and computers
  • Publish resources
  • Manage domains
  • Manage operations master roles
  • Manage COM+ partitions and partition sets
  • Search Active Directory
  • Change views


New ways to do familiar tasks

The following table lists common tasks for configuring Active Directory Users and Computers. The user interface for performing these tasks is different in this version of Windows from the way it was in Windows NT version 4.0.

Note

  • There are no significant user interface differences between Windows 2000 and the Windows Server 2003 family of products for this component.
If you want to | In Windows NT 4.0 use | In this version of Windows use
Manage user accounts | User Manager | Active Directory Users and Computers. For more information, see Manage users.
Manage groups | User Manager | Active Directory Users and Computers. For more information, see Manage groups.
Manage computer accounts | Server Manager | Active Directory Users and Computers. For more information, see Manage computers.
Add a computer to a domain | Server Manager | Active Directory Users and Computers. For more information, see Manage computers.
Manage account policy | User Manager | Active Directory Users and Computers. For more information, see Account and local policies.
Manage user rights | User Manager | Active Directory Users and Computers. Edit the Group Policy object for the domain or organizational unit containing the computers to which the user rights apply. For more information, see To edit a security setting on a Group Policy object.
Manage audit policy | User Manager | Active Directory Users and Computers. Edit the Group Policy object assigned to the Domain Controllers organizational unit. For more information, see To edit a security setting on a Group Policy object.


Active Directory Users and Computers

Active Directory® Users and Computers is the Microsoft® Management Console (MMC) that you can use to administer and publish information in the directory.

  • Before creating a group in Active Directory Users and Computers, see Checklist: Creating a group.
  • To find administrative tool equivalents that have been changed from Windows NT® 4.0 Server, see New ways to do familiar tasks.
  • For tips about using Active Directory Users and Computers, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.


Change views

  • View advanced features
  • Select view filter options


Checklists

  • Checklist: Configuring a site
  • Checklist: Optimizing intersite replication


Active Directory Sites and Services

Active Directory® Sites and Services is the Microsoft® Management Console (MMC) that you can use to administer the replication of directory data.

  • Before administering the replication of directory data, see Checklists.
  • For tips about using Active Directory Sites and Services, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.


Seizure of the domain naming master

The domain controller currently acting as the domain naming master is not available. This could be caused by network problems or by a failure of the domain naming master computer.

Temporary unavailability of the domain naming master is not visible to network users. Seizing the domain naming master role is a drastic step that should be considered only if the current domain naming master will never be brought back online.

Before proceeding with the role seizure, you must permanently disconnect the current domain naming master from the network. Use the repadmin command-line tool to perform the seizure.

Important

  • After the domain naming master role has been seized, the boot drive for the original domain naming master must be completely reformatted and the operating system reinstalled before that computer can be returned to the network.

For more information about operations master roles, see Operations master roles.


Seizure of the infrastructure master

The domain controller currently acting as the infrastructure master is not available. This could be caused by network problems or by a failure of the infrastructure master computer.

There should be an infrastructure master in each domain in a forest. Temporary unavailability of an infrastructure master is not visible to network users. Seizing the infrastructure master role is a drastic step that should be considered only if the current infrastructure master will never be available again.

Before proceeding with the role seizure, you must permanently disconnect the current infrastructure master from the network.

Important

  • After the infrastructure master role has been seized, the boot drive for the original infrastructure master must be completely reformatted and the operating system reinstalled before that computer can be returned to the network.

For more information about operations master roles, see Operations master roles.


Seizure of the PDC emulator

The domain controller currently acting as the primary domain controller (PDC) emulator is not available. This could be caused by network problems or by a failure of the operations master computer.

You can seize the PDC emulator role and force the role to transfer to another domain controller in the same domain. There should be a PDC emulator in each domain. Because the loss of the PDC emulator role can impact the usability of your network, you should forcefully transfer the PDC emulator role when you know that the current PDC emulator will not be available for an unacceptable length of time.

When the original PDC emulator becomes available again, you can transfer the role back to it.

For more information about operations master roles, see Operations master roles.


Seizure of the RID master role

The domain controller currently acting as the RID master is not available. This could be caused by network problems or by a failure of the RID master computer.

There should be a RID master in each domain. Temporary unavailability of a RID master is not visible to network users. Seizing the RID master role is a drastic step that should be considered only if the current RID master will never be available again.

Before proceeding with the role seizure, you must permanently disconnect the current RID master from the network.

Important

  • After the RID master role has been seized, the boot drive for the original RID master must be completely reformatted and the operating system reinstalled before that computer can be returned to the network.

For more information about operations master roles, see Operations master roles.


Seizure of the schema master role

The domain controller currently acting as the schema master is not available. This could be caused by network problems or by a failure of the schema master computer.

Temporary unavailability of the schema master is not visible to network users. Seizing the schema master role is a drastic step that should be considered only if the current schema master will never be available again.

Before proceeding with the role seizure, you must permanently disconnect the current schema master from the network.

Important

  • After the schema master role has been seized, the boot drive for the original schema master computer must be completely reformatted and the operating system reinstalled before that computer can be returned to the network.

For more information about operations master roles, see Operations master roles.


Checklist: Installing a domain controller

Step | Reference
(Optional) Review concepts about Active Directory. | Introduction to Active Directory
(Optional) Review role of a domain controller. | Domain controllers
(Optional) Review concepts about security and other options available when using the Active Directory Installation Wizard. | Using the Active Directory Installation Wizard
(Optional) If you are setting up Active Directory for the first time, review concepts on Domain Name System (DNS) namespace planning and how Active Directory is integrated with DNS. | Namespace planning for DNS; To configure a DNS server for use with Active Directory; DNS integration
Verify that the server on which you want to install Active Directory has an NTFS partition. | Reformatting or converting a partition to use NTFS
Verify that DNS is properly configured before installing Active Directory. | Checklist: Verifying DNS before installing Active Directory
Install the domain controller. | To create a new forest; To create a new domain tree; To create a new child domain; To create an additional domain controller


Active Directory Installation Wizard Help

Before using this wizard, learn more about Active Directory.

  • An introduction to Active Directory

    If this is the first time you are installing Active Directory, read the following topics for a thorough understanding of Active Directory:

    Introduction to Active Directory

    Domain controllers

    Domains

    Active Directory naming

    Upgrading from a Windows NT domain (if applicable)

  • An installation checklist

    The Active Directory Installation Wizard has four options to set up an Active Directory infrastructure. The following table will point you to the most relevant checklist for installing Active Directory in your organization.

    • To... | Follow this checklist...
Create an additional domain controller | Checklist: Creating an additional domain controller in an existing domain
Create a new forest | Checklist: Creating a new forest
Create a new child domain | Checklist: Creating a new child domain
Create a new domain tree | Checklist: Creating a new domain tree
  • Information about using this wizard

    For information specific to using this wizard, see Using the Active Directory Installation Wizard.

For the most up-to-date information about Active Directory, see the Microsoft Web Site (http://www.microsoft.com/).


Administering Active Directory Domains and Trusts

The following topics discuss information that you must consider when planning and installing or upgrading Active Directory® domains:

  • Using Run as
  • Managing Active Directory from MMC
  • Managing Active Directory from the command line
  • Administering other domains
  • Delegating administration


Command-line options

Active Directory Users and Computers has command-line options that allow you to start the console focused on a particular domain or domain controller. The command-line options support both fully qualified domain names and NetBIOS names.

The command-line options are:

  • /domain=FullyQualifiedDomainName
  • /domain=NetBIOSDomainName
  • /server=FullyQualifiedDomainControllerName
  • /server=NetBIOSDomainControllerName

You can use these command-line options to run Active Directory Users and Computers directly from the command line, or you can create a shortcut to start the console and add the command-line options to the shortcut. You can use the command-line options with Active Directory Users and Computers (dsa.msc) and with any custom consoles that you create. For more information about creating and saving console files, see Microsoft Management Console.

Command-line examples:

  • To start Active Directory Users and Computers focused on domain1, type dsa.msc /domain=domain1
  • To start Active Directory Users and Computers focused on server1, type dsa.msc /server=server1.

Note

  • You can use these command-line options to specify either the domain or the domain controller focus. Do not use both command-line options at the same time.


Incorrect security credentials

This error occurred because your current security credentials do not match the task you are trying to perform. You are logged on as a local user of this computer and you are attempting an Active Directory management task. For more information about managing local users and groups on this computer, see Local Users and Groups overview.

To perform Active Directory management tasks, you must be logged on as a member of a domain, for example, yourname@microsoft.com. For more information about how to manage users, groups, and computers in Active Directory, see Manage users, groups, and computers.


Locating a domain controller

When the logon process is initiated from computers running Windows 2000, XOX, or servers running Windows Server 2003, the Net Logon service is used to locate a domain controller, closest to the requesting computer, to authenticate the user request.

With the Active Directory client installed on computers running Windows 95, Windows 98, or Windows NT 4.0 and earlier, the domain controller location process is similar to computers running Windows 2000, XOX, or servers running Windows Server 2003.

For more information about Active Directory clients, see Active Directory clients.

The Net Logon service collects the required logon information for the domain to which the user is attempting to logon and sends a Domain Name System (DNS) name query to its configured DNS servers with the following characteristics:

  • Query type: SRV (Service locator resource record)
  • Query name: _ldap._tcp.domain_name

For example, to log on to the domain microsoft.com, computers running Windows 2000, XOX, or servers running Windows Server 2003 send a DNS name query of the type SRV for the name _ldap._tcp.microsoft.com. The response from the DNS server contains the DNS names of the closest domain controllers belonging to the microsoft.com domain and their IP addresses. Using the list of domain controller IP addresses, computers running running Windows 2000, XOX, or servers running Windows Server 2003 attempt to contact each domain controller to ensure that it is operational. The first domain controller to respond is the domain controller that is used for the logon process. Net Logon then caches the domain controller information so that any future requests from that computer do not attempt to repeat the same location process.

For more information about this process and other types of queries made by Active Directory clients, see the Windows Deployment and Resource Kits.


Best practices for Active Directory Schema

Microsoft Windows graphic

Best practices

  • Do not casually modify the schema.

    Modifying the schema is an advanced and complex operation best handled by experienced programmers and administrators. Developers may decide to modify the schema as part of the process of developing an application that will itself modify the schema. Advanced administrators may decide to modify the schema while troubleshooting an application that they suspect has itself incorrectly modified the schema. For information about modifying or extending the schema, see the Active Directory Programmer's Guide at the Microsoft Web site.

  • Develop and test your schema modifications on an isolated test forest.

    You should develop and test your schema updates on an isolated forest before moving them to your production forest.

  • Refer to the Active Directory Programmer's Guide.

    The Active Directory Programmer's Guide at the Microsoft Web site (http://www.microsoft.com/) is the best source of information about modifying the schema. Do not modify the schema without first consulting this document.

  • As a security best practice, it is recommended that you do not log on to your computer with administrative credentials.

    • When you are logged on to your computer without administrative credentials, you can use Run as to accomplish administrative tasks.

    For more information, see Why you should not run your computer as an administrator and Using Run as.

  • To further secure Active Directory, it is recommended that you implement the following security guidelines:
    • Rename or disable the Administrator account (and guest account) in each domain to prevent attacks on your domains. For more information, see User and computer accounts.
    • Physically secure all domain controllers in a locked room. For more information, see Domain controllers and Securing Active Directory.
    • Manage the security relationship between two forests and simplify security administration and authentication across forests. For more information, see Forest trusts.
    • To provide additional protection for the Active Directory schema, remove all users from the Schema Admins group, and add a user to the group only when schema changes need to be made. Once the change has been made remove the user from the group.
    • Restrict user, group, and computer access to shared resources and to filter Group Policy settings. For more information, see Security groups.
    • Avoid disabling the use of signed or encrypted LDAP traffic for Active Directory administrative tools. For more information, see Connecting to domain controllers running Windows 2000.
    • Some default user rights assigned to specific default groups may allow members of those groups to gain additional rights in the domain, including administrative rights. Therefore, your organization must equally trust all personnel that are members of the Enterprise Admins, Domain Admins, Account Operators, Server Operators, Print Operators and Backup Operators groups. For more information about these groups, see Default Groups.

      For general security information about Active Directory, see Security information for Active Directory and Securing Active Directory.


Concepts

This section provides general background information about the Active Directory schema:

  • Understanding the Active Directory schema
  • Administering the Active Directory schema
  • Resources


How to...

  • Install the Active Directory Schema snap-in
  • Add a member to the Schema Admins group
  • Remove a member from the Schema Admins group
  • Modify schema permissions
  • Add an attribute to the global catalog
  • Index an attribute in Active Directory
  • Index an attribute for a containerized search
  • View a schema class or attribute definition
  • Enable schema changes on a Windows 2000 domain controller
  • Modify a schema class or attribute definition
  • Add a schema class or attribute definition
  • Deactivate a class or attribute
  • Reactivate a class or attribute
  • Reload the schema
  • Identify the schema master
  • Transfer the schema master role
  • Seize the schema master role


Understanding the Active Directory schema

This section covers:

  • Schema
  • Schema classes and attributes
  • Schema object names
  • Deactivating a class or attribute
  • Extending the schema


Administering the Active Directory schema

This section covers:

  • Managing the Active Directory schema from MMC
  • Using Run as


The Active Directory Schema snap-in is not available

The Active Directory Schema snap-in has not been installed, or online Help was unable to locate the appropriate MMC console file.

For information about installing the Active Directory Schema snap-in and creating the appropriate MMC console file, see To install the Active Directory Schema snap-in.


Best practices for Active Directory Sites and Services

  • Establish as a site every geographic area that requires fast access to the latest directory information.

    Establishing areas that require immediate access to up-to-date directory information as separate sites will provide the resources required to meet your needs.

    For more information, see To create a site.

  • Place at least one domain controller in every site, and create a global catalog on at least one domain controller in each site.

    Sites that do not have their own domain controllers and at least one global catalog are dependent on other sites for directory information, making the utilization of network bandwidth between sites less efficient.

    For more information, see To create a new forest and To enable or disable a global catalog.

  • Monitor replication regularly.

    To help ensure a healthy network, monitor replication regularly. For more information, see Troubleshooting replication.

  • All sites must be associated with at least one subnet and in at least one site link, or they will not be usable.

    • For more information, see To associate a subnet with a site and To add a site to a site link.

  • Install an enterprise certification authority (CA) if any of your site links will use SMTP.

    If you choose to use SMTP over site links, you must install an enterprise CA. The CA signs SMTP messages that are exchanged between domain controllers, ensuring the authenticity of directory updates.

    For more information, see Installing and configuring a certification authority.

  • As a security best practice, it is recommended that you do not log on to your computer with administrative credentials.

    • When you are logged on to your computer without administrative credentials, you can use Run as to accomplish administrative tasks.

    For more information, see Why you should not run your computer as an administrator and Using Run as.

  • To further secure Active Directory, it is recommended that you implement the following security guidelines:
    • Rename or disable the Administrator account (and guest account) in each domain to prevent attacks on your domains. For more information, see User and computer accounts.
    • Physically secure all domain controllers in a locked room. For more information, see Domain controllers and Securing Active Directory.
    • Manage the security relationship between two forests and simplify security administration and authentication across forests. For more information, see Forest trusts.
    • To provide additional protection for the Active Directory schema, remove all users from the Schema Admins group, and add a user to the group only when schema changes need to be made. Once the change has been made remove the user from the group.
    • Restrict user, group, and computer access to shared resources and to filter Group Policy settings. For more information, see Security groups.
    • Avoid disabling the use of signed or encrypted LDAP traffic for Active Directory administrative tools. For more information, see Connecting to domain controllers running Windows 2000.
    • Some default user rights assigned to specific default groups may allow members of those groups to gain additional rights in the domain, including administrative rights. Therefore, your organization must equally trust all personnel that are members of the Enterprise Admins, Domain Admins, Account Operators, Server Operators, Print Operators and Backup Operators groups. For more information about these groups, see Default Groups.

      For general security information about Active Directory, see Security information for Active Directory and Securing Active Directory.


Services

Active Directory publishes a wide range of information. Domain controllers, in general, are designed to publish directory information and respond to service requests, but Active Directory publishes service-centric configurations or bindings. Publishing this sort of information makes the service more accessible to clients and more manageable for administrators.

Client and applications can get information from the directory. This information is then used to access services provided on network servers. In the following graphic, a client requests and receives service information from a domain controller (steps 1 and 2). This service information is then used to access a service being provided on a network server (step 3).

Client requests and receives service information from a domain controller, then uses this service information to access a service being provided on a network server

There is a set of services that are published in the directory by default, but you can extend this list to meet the needs of your network environment.

Publishing services to the directory provides a number of benefits:

  • Resource availability. A service-centric model makes accessing distributed network services a simpler task for clients. Because the services are published to the directory, clients do not need to store the resource's location. Potentially, any published service can be available from any server that is running Windows Server 2003.
  • Administration. Publishing service bindings enables you to modify those bindings or resolve configuration issues centrally, rather than from individual computers. This ensures that all services employ the latest configuration information.

For recommendations about the type of service information to publish, see Publishing resources.

By default, Active Directory Sites and Services does not display the services node, although you can choose to display it. The services displayed in the services node are usually best administered by tools specific to each service. Active Directory Sites and Services can generally provide only limited functionality for viewing or modifying most these services. For more information about displaying the services node, see To reveal the services node.


Understanding Active Directory Sites and Services

This section covers:

  • Securing Active Directory
  • Access control in Active Directory
  • Domain controllers
  • Renaming domain controllers
  • Domain and forest functionality
  • Application directory partitions
  • Managing application directory partitions
  • Group Policy integration
  • Understanding sites and replication
  • Understanding the global catalog


Concepts

This section provides general background information about Active Directory Sites and Services:

  • Active Directory overview
  • Understanding Active Directory Sites and Services
  • Administering Active Directory Sites and Services
  • Resources


How to...

  • Configure site settings
  • Configure server settings
  • Configure replication between sites


Administering Active Directory Sites and Services

This section covers:

  • Managing Active Directory from MMC
  • Managing Active Directory from the command line
  • Delegating administration
  • Publishing resources


Using Ntdsutil

Ntdsutil.exe is a command-line tool that provides management facilities for Active Directory. Use Ntdsutil to perform database maintenance of Active Directory, manage and control single master operations, remove metadata left behind by domain controllers that were removed from the network without being properly uninstalled, and create application directory partitions. The tool has a series of menus that allow you to move between different management tasks. This tool is intended to be used by experienced administrators. By default, Ntdsutil is installed in the systemroot\System32 folder and can be accessed at the command prompt. For command-line information about the Ntdsutil command-line tool, see Ntdsutil.

You can invoke Ntdsutil from the command prompt with no arguments. Rather than support and extend an ever-increasing set of cryptic command-line arguments, the tool parses keyboard input after you invoke it. For example, you can type the following:

    list roles for connected server

    connect to server xxx

For convenience, you need only specify enough of each word to make it unique with respect to any other words that you can enter in that specific menu. Thus, as you become more familiar with the tool, you could type li r f c s rather than list roles for connected server.

Processing command input

Ntdsutil processes as input all the arguments that you type when you start the program. For example, if you type the following:

    ntdsutil help connections help quit quit

Ntdsutil does the following steps:

  1. Invokes Ntdsutil.exe.
  2. Displays its Help information.
  3. Invokes the Connections submenu.
  4. Displays its Help information.
  5. Closes the Connections submenu and returns to the top-level menu.
  6. Quits the program.

Automating Ntdsutil commands

You can automate Ntdsutil by creating batch files or scripts that contain a series of Ntdsutil commands. Many Ntdsutil commands that perform writes, open by default a message that asks users if they really want to perform a particular operation. When these messages appear, the program will pause and wait for keyboard input. Use the Popups %s command to disable these messages when running Ntdsutil from a batch file or script. For example, to disable these messages, type the following:

    popups no

To reenable the display of these messages, type the following:

    popups yes

It is good practice to disable these messages only when you are scripting Ntdsutil commands and to reenable them as soon as you finish scripting.

Errors in Ntdsutil

Ntdsutil does not provide error level kick back or fail overs. The only way to verify that changes were made is to pars, then view the log file.


Administration tools for the Active Directory schema

You can use the following tools to administer the Active Directory schema (listed in order of general preference):

Name | Description
Schema MMC snap-in | The easiest way to view and edit the schema. For information about installing the schema MMC snap-in, see To install the Active Directory Schema snap-in.
Ldifde | The preferred way to push tested schema extensions into the production environment. In addition, can extend the schema, export Active Directory user and group information to other applications or services and populate Active Directory with data from other directory services. For more information, see Ldifde.
ADSI Edit MMC snap-in | Acts as a low-level editor for Active Directory. View all objects in the directory (including schema information), modify objects and set access control lists on objects. Available on the installation CD in the \Support\Tools folder. For information about installation, see To install Windows Support Tools.
LDP | A GUI-based support utility. Perform Lightweight Directory Access Protocol (LDAP) operations (connect, bind, search, modify, add, delete) against any LDAP-compatible directory, such as Active Directory. Available on the installation CD in the \Support\Tools folder. For information about installation, see To install Windows Support Tools.
Csvde | Import and export data from Active Directory using files that store data in the comma-separated variable (CSV) format. Supports batch operations based on the CSV file format standard. For more information, see Csvde.

For information about modifying the schema, see Extending the schema and Deactivating a class or attribute.

For information about tools available from the Microsoft Windows Server 2003 Resource Kit, see "Tools and Technical References" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

For information about command-line tools, see Command-line reference A-Z.


Active Directory Schema

The Active Directory® Schema snap-in is the Microsoft® Management Console (MMC) that you can use to administer the types of objects stored in Active Directory.

  • For tips about using the Active Directory Schema snap-in, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.